Re: [libc-alpha] Re: [libc-alpha] Re: [open-source] Re: Wish for 2002

[James Antill <james at and dot org>]

Valentin Nechayev <netch@lucky.net> writes:

> (Cc list wasn't cut)
> 
>  Tue, Jan 08, 2002 at 18:42:06, kaz wrote about "Re: [libc-alpha] Re: [libc-alpha] Re: [open-source] Re: Wish for 2002": 
> 
> > > PA02: Assess Impact (page 121)
> > > What all GNU/Linux most GNU applications on other OSes have in common ?
> > > glibc 
> > 
> > This dependency means that once you add functions to glibc, you have to
> > support them indefinitely. The functions in questions have poorly
> > defined semantics. For example, I can't find anything in the BSD
> > man pages regarding what the behavior should be of
> > 
> >   strlcat(buffer, buffer, sizeof buffer);
> 
> I can't find anything in the glibc man pages what the behavoir should be
> of strcpy(buffer,buffer). Does this mean that strcpy() is poorly
> documented in glibc and should be removed? No smiles here.

 strcpy() is a standard function, C99 says (among other things)...

7.21.2.3  The strcpy function

[snip ... ]

[#2]  The strcpy function copies the string pointed to by s2
       (including the terminating null character)  into  the  array
       pointed  to  by  s1.  If copying takes place between objects
       that overlap, the behavior is undefined.

> > should be considered undefined, will it change in the future? The
> > current specification is written by people who don't know how to
> > write standards. They haven't even managed to get the man page to match
> > with the implementation.
> 
> Please describe the exact inconsistency with exact and full specification
> of version in use. For current FreeBSD and OpenBSD, I cannot find such.

 As Kaz Kylheku <kaz@ashi.footprints.net> said:

By the way, what are the correct semantics for strlcat? The OpenBSD
source code has a return value that contradicts various BSD man pages.
According to the man pages, the return value is always the sum of
the length of the two original strings. According to the OpenBSD source
code, if the copy limit is smaller than the destination string that is
to be appended to, then the return value is the limit plus the length
of the second string.

> It can be proven with quite enough probability that each program larger
> than "Hello, world!", working with text and having strc*() in its code
> has buffer overruns, unless irrational money was spent to fix its bugs.
> glibc is distinctive example of large program.

 By the same reasoning it can be "proven with quite enough
probability" that any non trivial program using strlcpy() corrupts
input data.
 Look if you want to use strlcpy() go for it, if you want to use a
"real" string library go do that too ... there are a few for C.

> You are against strlc*() and this is the real reason why you are against
> them in glibc; if you were "pro" them, you would vote to include them. glibc
> contains a lot of "non-standard" BSD compatibility stuff, and nobody
> died due to its inclusion. To append two little and useful functions,
> heaven won't fall to land, but standartizing of strlc*() will got a solid
> help, also helping to remove obsolete crap.

 But what will strlcat()/strlcpy() be standardized as? If glibc
includes them and has to then change the interface that would be
_much_ worse than not including it until it becomes standard.

 As for the current non standard stuff in glibc, then I instantly
think of asprintf() which is different in the error path from BSD and
isn't documented as such. So if you use the non standard system
version over a portable one in your program, then you have to just
"know" about it's quirks or you are going to get burned.

> > C++, which is still a Stone Age programming language, has std::string.
> > Now if you don't like someone pushing C++ at you, then don't push some
> > functions onto others.
> 
> Yes, and this is the great step comparing to nul-terminated strings.
> Does this mean IYO that all C programs working with text should be
> immediately converted to C++ programs?

 Replace C++ with perl/python/a decent bunch of dynamic string
functions for C.

-- 
James Antill -- <james@and.org>
Firewall n.
 1. A bad security program used to make other bad security programs less
baddly in need of security.