HDTenEightyP/NetNews huggingface dataset:
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: Typedef Problem
Date: 13 Apr 92 12:09:43 EDT

diamond@jit345.bad.jit.dec.com (Norman Diamond) writes:
>In article <1992Mar28.153738.20577@mcshh.Hanse.DE> buster@mcshh.Hanse.DE (Andreas Burmester) writes:
>>To handle strings, I've typedefed
>>        typedef char CA[];
>>and ran into a problem, I could track down to these definitions:
>>(0)     CA s0 = "string 0";
>>(1)     CA s1 = "s1";
>>(2)     CA s2 = "this is string 2";
>>The translator passes (0) and (1), while at (2), it complains
>>that "The initializer length exceeds the aggregate length." A
>>closer inspection reveals already at (1) things go (at least for
>>me) unexpected ways: There are 9 bytes allocated for s1 - note,
>>that strlen(s0) == 9 !
>>It's obvious that, having processed (0), CA is 'retypdefed' to
>>char CA[9]. Then the initializer of s2 is indeed too long.

>My understanding of "Array declarators" (ANSI 3.5.4.2) is that the type CA
>is an array type and is an incomplete type.  [3.5.4.2 is missing from the
>index for "type, incomplete" in the last draft edition.]

And in the final version, but it adds no new information over the first
definition in "Types", which is probably the reason for the omission.

>My understanding of "Initialization" (ANSI 3.5.7) is that when an array of
>unknown size is initialized, the array is the one in the declarator.  The
>array whose size is determined by the number of initializers, and which no
>longer has incomplete type, is the one in the declarator.  This would be
>s0, s1, or s2.  I don't believe that it would be CA.

The key here, I think, is that the type of s0, s1, and s2 is not "CA".
The type of those objects is array-N-of-char, where N is filled in when
the object is fully declared.  The identifier CA is just "a synonym for
an existing type", namely array-incomplete-of-char.  Typedefs are not types.

This compiler is wrong from ANSI's viewpoint.
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: const T **
Keywords: const
Date: 15 Apr 92 11:28:32 EDT

smclewin@ultrix.ramapo.edu (Scooter McLune) writes:
>donne@imec.be (Werner Donne) writes:
>>int
>>main(void)
>>{
>>  const char **a;
>>  char **b;
>>  a = b;
>>  return 0;
>>}

>The assignment cannot be done because **a is a constant variable, by your
>definition.  If you were to do the assignment "b = a" with the code you
>have above, there would be no problem.

No.  "b = a;" is illegal for the same reason "a = b;" is; the two objects
are not pointers to compatible types (const char * is not compatible with
char *). 

Your first sentence is confusing; are you arguing that a is constant (false,
that would be "char ** const a"), or that "a = b;" somehow would modify the
const object at **a (false)?
Newsgroups: comp.std.c,comp.std.c++
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: min, max, and ANSI
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Fri, 10 Apr 92 08:29:56 GMT

In article <1992Apr9.165859.18578@wam.umd.edu> krc@wam.umd.edu (Kevin R. Coombes) writes:
>I have a question about the ANSI C header stdlib.h. A certain compiler that
>shall for the moment remain nameless includes macros for min(a,b) and
>max(a,b) in <stdlib.h>.

1.  If you're asking about the ANSI C header stdlib.h, it does not intrude
on the application's namespace, not even names like min and max.

2.  If you're asking about the draft ANSI C++ standard (for which you
cross-posted your question), you'll have to hope for an answer from
someone else.

3.  If you're asking about a certain nameless compiler, then maybe:
(a)  You might have invoked it in a non-conforming mode, and/or your program
might have done something to request implementation extensions, and in either
case the standard becomes irrelevant.  Please note that non-conforming modes
are often defaults, and often you have to use options for conforming modes; or
(b)  The vendor might not have asserted conformance in the first place; or
(c)  If you did everything as directed to invoke in a conforming mode, then
you should demand a refund from the vendor.  [Personal opinion only.]
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."
Newsgroups: comp.std.c
From: atbowler@thinkage.on.ca (Alan Bowler)
Subject: Re: PLease advise about "ansi" headers
Keywords: headers, conformance, ansi, hell
Organization: /etc/organization
Date: Thu, 16 Apr 1992 22:03:43 GMT

In article <1992Apr5.001734.26988@taumet.com> steve@taumet.com (Steve Clamage) writes:
>atbowler@thinkage.on.ca (Alan Bowler) writes:
>
>>In article <1992Apr1.175309.19833@taumet.com> steve@taumet.com (Steve Clamage) writes:
>>>    long *ip = &y.rem; /* legal but disallowed by this implementation */
>>the implementation might consider it legal.
>
>In other words, a compiler which claims conformance to the Standard
>would allow
>	int i;
>	long *ip = &i;	/* type conflict */
>I think this is much worse than making div_t and ldiv_t the same type.
>
Ooops. You are right.  The compiler is supposed to complain about this
type of assignment.

>>Even longer delays often occur with the site system administration not
>>bothering to install newer releases.  I would bet that in this case,
>>the version of the implementation simply predates the standard, and
>>newer release fix some of the problems outlined.
>
>This is certainly possible.  We would have to hear from the original
>poster (sorry, forgot who it was) whether it is the case.

Another message said that there were 1990 and 1991 dates in the
headers.  This is certainly very late to have the sort of errors
described in the original post.  I wrote my message shortly after
finding that the delivery pipeline for some of our customers is just
about to deliver the 5 year old version of some of our software.
Fortunately most customers have received newer versions.
Xref: sparky comp.std.c:1786 gnu.gcc.bug:1039
From: qbarnes@urbana.mcd.mot.com (Quentin Barnes)
Newsgroups: comp.std.c,gnu.gcc.bug
Subject: ANSI C spec and GNU C preprocessing
Date: 9 Apr 92 21:39:00 GMT
Followup-To: comp.std.c,gnu.gcc.bug
Organization: Motorola Computer Group, Urbana Design Center
Apparently-To: gnu-gcc-bug@uunet.uu.net

I have a few questions about the ANSI C spec (X3.159-1989 section
3.8) and how an ANSI C preprocessor should behave. 

We are using GNU C's preprocessor and as far as I can tell from the
ANSI C spec, it does not follow it on the items below.

1) When a conforming preprocessor encounters a '#' directive which
   is not listed in the preprocessor syntax (ex. '#foo'), what is
   the correct behavior -- declare a fatal error, display a warning,
   or pass it unchanged silently to the compiler?

   GNU C silently passes it on and lets the compiler catch the error.
   Since the spec doesn't say you can do that, I would read that as you
   can't do it, so it would be a fatal error from the preprocessor.
   I can't find a place in the spec that says this though.

2) A conforming preprocessor must output line directives (3.8.4)
   in the format:

	'# line digit-sequence new-line', or 
	'# line digit-sequence "s-char-sequence" new-line'

   The spec allows the general format (3.8.4-15), however, after token
   replacement it must match one of the two above forms.

   Upon entering or exiting a "new" source file, GNU C's preprocessing
   appends the numeral "1" (for entering) or a "2" for exiting.  An
   example line would be:

	# line 34 "myheader.h" 1

   Since this example does not follow the spec, it is not ANSI compliant.
   Correct?

3) An alternate form of the '#line' directive would not use the keyword
   'line'.  For example:

	# 34 "myheader.h"

   This is the default behavior of GNU C's preprocessor unless compiled
   with "OUTPUT_LINE_COMMANDS".  I assume that to be ANSI compliant, the
   preprocessor must generate the 'line' keywoard and the example is
   not compliant.

-- 
Quentin Barnes
qbarnes@urbana.mcd.mot.com | ..!uiucuxc!udc!qbarnes
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.std.c
Subject: Re: const T **
Keywords: const
Date: 15 Apr 92 04:38:51 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <1611@imec.UUCP> donne@imec.be (Werner Donne) wrote:
> Why is the assignment illegal?
In article <1992Apr15.014523.5364@cs.mcgill.ca>,
storm@cs.mcgill.ca (Marc WANDSCHNEIDER) replied:
> As far as I can see, it isn't.  I ran it on cc for the NeXTs, gcc
> running under SunOS 4.1.1 and as well, on MSC and Borland C++ 3.0 on my
> PC in front of me...  Not one compiler even complained about the assignment.

Encore Multimax running their version of 4.3BSD:
% cat foo.c
int main(void) { const char **a; char **b; a = b; return 0; }
% gcc -ansi -pedantic foo.c
foo.c: In function main:
foo.c:1: warning: assignment between incompatible pointer types

Quite right too.  The handling of read/write modifiers on pointers
was pretty well worked out in Mark Rain's "MARY" language, so there
was relevant (MARY was an Algol-68-derivative for systems programming)
prior art.
-- 
I am writing a book on debugging aimed at 1st & 2nd year CS students using
C/Modula/Pascal-like languages.  Please send suggestions (other than "you
_must_ cite "C Traps and Pitfalls") to ok@goanna.cs.rmit.oz.au
Xref: sparky comp.std.c:1789 gnu.gcc.bug:1043
From: sef@kithrup.COM (Sean Eric Fagan)
Newsgroups: comp.std.c,gnu.gcc.bug
Subject: Re: ANSI C spec and GNU C preprocessing
Date: 11 Apr 92 07:38:42 GMT
Article-I.D.: kithrup.1992Apr11.073842.6058
Followup-To: comp.std.c,gnu.gcc.bug
Organization: Kithrup Enterprises, Ltd.
X-Mailer: SCO System V Mail (version 3.2)
To: uunet.uu.net!gnu-gcc-bug@kithrup.com

In article <1992Apr9.213900.26576@urbana.mcd.mot.com> qbarnes@urbana.mcd.mot.com (Quentin Barnes) writes:
>I have a few questions about the ANSI C spec (X3.159-1989 section
>3.8) and how an ANSI C preprocessor should behave. 

The ANSI C spec does not differentiate between a preprocessor and a
compiler.  To put it another way, there is no guarantee that you can expect
to have anything happen if you use them other than as a whole.  Since you
seem to be wanting to use cccp only, you cannot expect ANSI C to help you in
any way, shape, or form, except, possibly, as a guide to how cccp might (or
might not) work.

-- 
Sean Eric Fagan  | "One form to rule them all, one form to find them, one
sef@kithrup.COM  |  form to bring them all and in the darkness rewrite the
-----------------+  hell out of them" -- sendmail ruleset 3 comment from DEC.
Any opinions expressed are my own, and generally unpopular with others.
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: overlapping objects
Keywords: ANSI
Date: 15 Apr 92 11:45:19 EDT

andrew@lsa.ncl.omron.co.jp (Andrew Walduck) writes:
>What exactly is an overlapping object in ANSI??

The Standard does not appear to have an explicit definition, so one has
to rely on common sense.  Two objects overlap if they share any storage
at all.

>char buffer[5];
>memcpy(buffer, buffer, 5);
>Is this a call to memcpy with overlapping objects?? 

Yes.

>And so...its perfectly alright for memcpy to dump core?? 

"The behavior is undefined."  It may dump core, it may work, it may set fire
to your collection of rare Beatles LPs.
Xref: sparky comp.std.c:1797 gnu.gcc.bug:1058
From: qbarnes@urbana.mcd.mot.com (Quentin Barnes)
Newsgroups: comp.std.c,gnu.gcc.bug
Subject: Re: ANSI C spec and GNU C preprocessing
Date: 12 Apr 92 23:50:16 GMT
Followup-To: comp.std.c,gnu.gcc.bug
Organization: Motorola Computer Group, Urbana Design Center
Apparently-To: gnu-gcc-bug@uunet.uu.net

In <1992Apr9.213900.26576@urbana.mcd.mot.com> qbarnes@urbana.mcd.mot.com (Quentin Barnes) writes:

>I have a few questions about the ANSI C spec (X3.159-1989 section
>3.8) and how an ANSI C preprocessor should behave. 

>We are using GNU C's preprocessor and as far as I can tell from the
>ANSI C spec, it does not follow it on the items below.

[stuff deleted]

Thank you all for the quick replies.

My questions arose from having to analyze a commerical C and C++ 
test suite.  Apparently the test suite writers were even more
confused than I was over the ANSI spec.

-- 
Quentin Barnes
qbarnes@urbana.mcd.mot.com | ..!uiucuxc!udc!qbarnes
Xref: sparky comp.std.c:1776 comp.std.c++:378
From: cwalker@albiero.tmc.edu (carleton walker `93)
Newsgroups: comp.std.c,comp.std.c++
Subject: Re: min, max, and ANSI
Date: 9 Apr 92 20:04:53 GMT
Organization: Bucknell University, Lewisburg, Pa.

In article <1992Apr9.165859.18578@wam.umd.edu> krc@wam.umd.edu (Kevin R. Coombes) writes:
>I have a question about the ANSI C header stdlib.h. A certain compiler that
>shall for the moment remain nameless includes macros for min(a,b) and 
>max(a,b) in <stdlib.h>. Consequently, I managed to lose several hours
>trying to find out why a working program suddenly broke---eventually
>discovering, of course, that I had been using min as the name of a variable,
>and had changed things hwen I #included <stdlib.h> for unrelated reasons.
>Are min and max SUPPOSED to be in stdlib.h, and have I been just lucky
>in avoiding this problem in the past?

	I've always used the MIN and MAX in <mp.h>. I took a peak in
<stdlib.h> and couldn't find a MIN or MAX function. Do you include
<mp.h>?


Carl Walker

--
Carl Walker				"Hectic days ahead of us,
Bucknell University			 Rotten ones behind,
Lewisburg, PA				 Keeping plastics in our pockets,
					 Children never mind." - K, S, & W
From: buster@mcshh.Hanse.DE (Andreas Burmester)
Newsgroups: comp.std.c
Subject: Typedef Problem
Date: 28 Mar 92 15:37:38 GMT
Organization: Point of Precense Hamburg


I'm dealing with a macro that also takes the type of a variable 
as parameter. To handle strings, I've typedefed

        typedef char CA[];

and ran into a problem, I could track down to these definitions:

(0)     CA s0 = "string 0";
(1)     CA s1 = "s1";
(2)     CA s2 = "this is string 2";

The translator passes (0) and (1), while at (2), it complains 
that "The initializer length exceeds the aggregate length." A 
closer inspection reveals already at (1) things go (at least for 
me) unexpected ways: There are 9 bytes allocated for s1 - note, 
that strlen(s0) == 9 !

It's obvious that, having processed (0), CA is 'retypdefed' to 
char CA[9]. Then the initializer of s2 is indeed too long.

Any comments?

Andreas

PSs.
     The compiler, to name it, is ECO-C, a pre-ANSI translator.

     I got my code work by using a CP (typedef char *CP) instead 
     of CA - of cause this is not what I originally meant.
Newsgroups: comp.std.c
From: dat@thinkage.on.ca (David Adrien Tanguay)
Subject: Re: PLease advise about "ansi" headers
Keywords: headers, conformance, ansi, hell
Organization: Thinkage, Ltd.
Date: Sat, 4 Apr 1992 11:47:26 GMT

diamond@jit.dec.com (Norman Diamond) writes:
>In article <*}s-pkdc@twinsun.com> eggert@twinsun.com (Paul Eggert) writes:
>>ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>>>    Am I correct that ANSI header files should be independent of identifiers
>>>    available to the user, using instead e.g.
>>>	void *malloc(size_t);		/* no identifier, or */
>>>	void *malloc(size_t _size);	/* reserved identifier */
>>You're basically correct.  A nit: `_size' isn't reserved (see ANSI C 4.1.2.1).
>>`__size' is, so it would work here.
>
>Mr. O'Keefe's complaint is correct, and his proposed adjustment was correct
>though on thin ice [personal opinion only].  Mr. Eggert's nit is wrong.
>
>The standard headers must be included outside of any external declaration or
>definition (ANSI 4.1.2, page 97 lines 31-32; there are also more requirements).
>
>_size is reserved for use as an identifier with file scope in both the
>ordinary and tag name spaces (ANSI 4.1.2.1, page 98 lines 7-8 and 16-18).
>I think the standard's wording is very unclear on whether _size can be
>declared as a macro, but footnote 88 clarifies the intention, and an
>implementation COULD depend on _size as a reserved identifier at file scope.

ANSI 3.1.2 pg. 21 line 5 "Macro names and macro parameters are not considered
further here", so macro names aren't in the "identifier with file scope"
category, and aren't reserved by 4.1.2.1 lines 7-8.

Footnote 88 says "macro names matching any of the reserved identifier names
must not be defined if an associated header, if any, is included".
                          ^^^^^^^^^^
"_size" is not associated with any of the headers, so I don't think it's
covered by the footnote, either.

Your interpretation seems to say that the user cannot define any macros that
start with an "_", at least if any standard header is included.

>So it's pretty hard to argue that the standard would allow the user to define
>_size as a macro in the part of a file where standard headers can be included.

Hey, it's the weekend, and I'm feeling reckless.

>(However, if I were an implementor, I would use two underscores in all of
>this kind of implementation stuff [personal opinion only].)

Ditto. And, as a user, I never create identifiers that start with an _:
it's a much easier rule to figure out and remember.

Reserved identifiers are strange and striking!
-- 
David Tanguay       dat@Thinkage.on.ca  dat@Thinkage.com  uunet!thinkage!dat
Thinkage, Ltd.           Kitchener, Ontario, Canada          [43.40N 80.47W]
From: andrew@lsa.ncl.omron.co.jp (Andrew Walduck)
Newsgroups: comp.std.c
Subject: va_list in stdio.h
Keywords: standard interpretation
Date: 13 Apr 92 11:12:55 GMT
Reply-To: andrew@lsa.ncl.omron.co.jp (Andrew Walduck)

I'm currently developing a set of header files for ANSI C. 
One thing I noticed is that in stdio.h, there are several functions that
accept a parameter of type va_list (vprintf, vsprintf, vfprintf). Yet...nowhere
in the standard does it say that stdio.h defines the type va_list.
So I'm assuming that stdio.h does NOT define type va_list...
and I can just use my hidden type (__va_list) in its place...

This is my implemention...is it correct??

...in xximpl.h xx

typedef void* __va_list;

...in stdarg.h

#include <xximpl.h>
typedef __va_list va_list;

...in stdio.h

#include <xximpl.h>
int vfprintf(FILE*, const char*, __va_list);
int vprintf(const char*, __va_list);
int vsprintf(char*, const char*, __va_list);

Thanx
Andrew Walduck
P.S. Yes...I know...I do use the #ifndef #define #endif wrappers around my
     include files... to protect against multiple definitions and
inclusions! ;-)

Andrew Walduck -- OMRON Japan -- andrew@lsa.ncl.omron.co.jp 
-------------------------------------------------------------------------------
Henry Spencer says "Retch barf." 
-------------------------------------------------------------------------------
From: qbarnes@urbana.mcd.mot.com (Quentin Barnes)
Newsgroups: comp.std.c
Subject: GNU C preprocessor and the ANSI C spec
Date: 10 Apr 92 20:30:07 GMT
Organization: Motorola Computer Group, Urbana Design Center

(This is my third attempt at posting this article with the first
 two were trached by news so hopefully there are no duplicates.)

In working with the GNU C preprocessor, I have come across several
behaviors which appear to deviate from the ANSI C spec (X3.159-1989).
I am hoping to have someone knowledgeable in the spec will confirm or
deny my suspicions. 

1) In chapter 3.8 which discusses C preprocessing, no mention is
   made of what should occur when a '#' directive is encountered
   which does not fall under the preprocessor syntax.  I would
   assume that unrecognized '#' directives would be an error
   in the preprocessing stage.  For example, if the input file
   has '#foo', what is the correct ANSI C behavior?

   The GNU C preprocessor silently passes unrecognized directives to
   the compiler and expects the compiler to declare the error.

2) For line control (3.8.4), the preprocessor must use '#line'.
   An alternate syntax '# digit-sequence' is not legal under ANSI C.

   The GNU C preprocessor will generate '#line' style if compiled
   with OUTPUT_LINE_COMMANDS otherwise it generates the alternate
   syntax.  To be closer to ANSI C compliance, the preprocessor must
   be built with this compile time option defined.  Correct?

3) The ANSI C spec in 3.8.4 states that '#line' directives must be
   of the format:
	# line digit-sequence new-line
   or
	# line digit-sequence "s-char-sequence" new-line

   In 3.8.4 around line 20, the spec does state that the form:
	# line pp-tokens new-line
   is allowed, but after processing the tokens, the syntax must
   fall into one of the first two forms.

   The GNU C preprocessor will generate '#line' directives in the
   format which adds a digit "1" or "2" if entering or exiting an
   included file.  For example:
	# line 34 "myfile.h" 1

   This seems in violation of the ANSI C spec.
-- 
Quentin Barnes
qbarnes@urbana.mcd.mot.com | ..!uiucuxc!udc!qbarnes
Xref: sparky comp.std.c:1813 comp.std.c++:393
From: donne@imec.be (Werner Donne)
Newsgroups: comp.std.c,comp.std.c++
Subject: const T **
Keywords: const
Date: 14 Apr 92 14:24:03 GMT
Followup-To: comp.std.c
Organization: IMEC vzw, 3030 Leuven, Belgium

int
main(void)

{

  const char **a;
  char **b;

  a = b;

  return 0;

}


Why is the assignment illegal?


Werner.
-- 
Quick to judge, quick to anger, slow to understand.
Ignorance and prejudice and fear walk hand in hand.

Neil Peart.
Xref: sparky comp.std.c:1790 gnu.gcc.bug:1044
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.std.c,gnu.gcc.bug
Subject: Re: ANSI C spec and GNU C preprocessing
Date: 11 Apr 92 07:58:13 GMT
Article-I.D.: dog.22650
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
Followup-To: comp.std.c,gnu.gcc.bug
Organization: Lawrence Berkeley Laboratory, Berkeley
To: gnu-gcc-bug@cis.ohio-state.edu
NNTP-Posting-Host: 128.3.112.15

In article <1992Apr9.213900.26576@urbana.mcd.mot.com>
qbarnes@urbana.mcd.mot.com (Quentin Barnes) writes:
>I have a few questions about the ANSI C spec (X3.159-1989 section
>3.8) and how an ANSI C preprocessor should behave. 

The ANSI standard does not concern itself with separate preprocessors.
It defines only a `preprocessing phase' of C compilation.  Whether that
is implemented separately, or as part of an integrated compiler program,
is up to the implementation.

>1) When a conforming preprocessor encounters a '#' directive which
>   is not listed in the preprocessor syntax (ex. '#foo'), what is
>   the correct behavior -- declare a fatal error, display a warning,
>   or pass it unchanged silently to the compiler?

When a conforming *compiler* (including all 7 phases) encounters an
program violating a constrant, it must emit at least one diagnostic.

>2) A conforming preprocessor must output line directives (3.8.4) ...

3.8.4 deals with *input* line directives.

GCC's cpp could emit encrypted binary data and still conform, as long as
the rest of the system performed according to the specifications.

The C standard acts as a contract between a `user' and an
`implementor'.  Each may view the other as a `black box'.  The user is
required to feed the implementor conforming code; the implementor is
required to accept conforming code and produce conforming output.

The black boxes, in this case, are defined only at the level of `C
source code' and `observable behavior when running the compiler and the
compiled code'.  The preprocessor, if there is a separate one, is not
considered an `observable part'.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
From: andrew@lsa.ncl.omron.co.jp (Andrew Walduck)
Newsgroups: comp.std.c
Subject: overlapping objects
Keywords: ANSI
Date: 15 Apr 92 11:22:49 GMT
Reply-To: andrew@lsa.ncl.omron.co.jp (Andrew Walduck)

What exactly is an overlapping object in ANSI??

For example:

char buffer[5];
memcpy(buffer, buffer, 5);

Is this a call to memcpy with overlapping objects?? 
And so...its perfectly alright for memcpy to dump core?? 

Thanx
Andrew Walduck

Andrew Walduck -- OMRON Japan -- andrew@lsa.ncl.omron.co.jp 
-------------------------------------------------------------------------------
Henry Spencer says "Retch barf." 
-------------------------------------------------------------------------------