AVR-Chat

On Tue, Feb 22, 2005 at 02:21:51PM -0500, Robert Adsett wrote:

"At 08:06 PM 2/22/05 +0100, Paul Colin Gloster wrote:
[..]

>The original ANSI C has an
>inefficient library routine which was knowingly standardized as such
>because many of the implementations of the function in draft 1980's ANSI C
>were buggy to the point of gross ineffiency, even though this function had
>originally been proposed with the motivation (and simple implementation of
>being) efficient. And years after current ANSI C was standardized in 1999,
>few ANSI C compilers have ever been released.

library routine?  Block locals have been legal since pre-ANSI AFAIK and 
[..]"

I was not thinking of declarations within a block. I was probably 
incompletely remembering the following thread "accu-general: Rationale 
for behaviour of strncpy() in C89/C99" on accu-general@ACCU.org :

timestamped Wed, 03 Jan 2001 08:45:47 +0000
an email from someone contained:

"Hiya!

I came across something recently which puzzled me slightly simple because I
can't work out *why* the standard was written in the way it is.  Allow me
to explain - consider the code:

	char string[16];

	memset(string, '*', sizeof(string));
	strcpy(string, "Hi");	
	strncpy(string, "Hello World", sizeof(string));

After the strcpy(),  string contains "Hi\0*************".  This seems quite
reasonable - the minimum number of bytes have been changed to copy the
string.  

After the strncpy(),  string contains "Hello World\0\0\0\0\0" - an extra 4
bytes have been assigned values by this call,  despite the fact that this
does not affect the representation of the string at all.  In this case the
speed penalty is almost negligible,  however if the array had been declared
somewhat larger,  it may become quite significant.  

C89 demands this behaviour in 7.11.2.4,  and C99 in 7.15.2.4(3).  Can
anybody explain to me what the thinking was behind the behaviour of
strncpy(),  and why the other strn...() functions [and snprintf()] don't
have the same behaviour?

Wishing you a Bug-free New Year..."


followed by an email from Jim Hyslop <Jim.Hyslop@Leitch.com>
time stamped Wed, 3 Jan 2001 09:33:58 -0500 :

"Well, as I understand it (and I may be perpetuating an urban legend) the
current, standard behaviour of strncpy is actually a bug. When the function
was originally written, it didn't behave the way it was *supposed* to
behave. But some programs got written to depend on the buggy behaviour, so
the buggy behaviour became the de facto standard behaviour.

Jim"

followed by an email from another person timestamped Wed, 3 Jan 2001 10:03:08 -0800 :

"According to "Rationale for American National Standard for Information
Systems - Programming Language - C" (
http://www.lysator.liu.se/c/rat/title.html#4-11 ) 

4.11.2.4  The strncpy function
strncpy was initially introduced into the C library to deal with
fixed-length name fields in structures such as directory entries.  Such
fields are not used in the same way as strings: the trailing null is
unnecessary for a maximum-length field, and setting trailing bytes for
shorter names to null assures efficient field-wise comparisons.  strncpy is
not by origin a ``bounded strcpy,'' and the Committee has preferred to
recognize existing practice rather than alter the function to better suit it
to such use.  

[ACCU mailing list details, see http://accu.org/mailinglists.htm ]"