This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


 Wed, Jan 09, 2002 at 10:29:42, james wrote about "Re: [libc-alpha] Re: [libc-alpha] Re: [open-source] Re: Wish for 2002": 

> > 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.

The point that Kaz Kylheku omitted is that length of dst is checked
__only in bounds of buffer specified__. I should repeat my previous
words (with some paraphrasis and emphasis):

- There is *no* infinite character buffer in real life.
- There is concept of *character buffer with limited, specified size*.

strlcat() checks length of dst only up to dst[size-1]; maximal reported
value can be == size. strlcat() *must not* check dst[size], dst[size+1]
or any character rightmore; the first reason is that memory block can
end after dst[size-1], and dst[size] can be nonexistent.

With such vital clarification, manpage and code are totally synchronized.
And I don't want see code as Kaz Kylheku's may want, because I don't
want to see program segfaulting without reason.

>  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.

I again request anybody to show such text in glibc or Linux man, not in C99
standard. ;)) Oh, glibc does not contain manpages...

> > 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.

The program which was converted from strcpy(), can corrupt input
data (in the way cutting it to buffer size). But, in case of strlcpy(),
programmer can simply check for this corruption.
And why you think that program with strcpy() does not perform such
corruption? If it writes to data after buffer - another variables, etc.,
then, when these variables change, input data also become corrupted,
moreover, in worse way.

>  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.

Why you think that the way strlc*() provides:

/* pseudo code */
	if( strlcat( b, c, sizeof b ) >= b ) THROW_OVERFLOW;

does not allow simple checking of overflows? Of course, it does not allow
buffer expanding and other "tastes" of "real" dynamic string library.
But local aim is to provide secure work, not to work in space rocket.

> > 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.

Why interface can be changed?
Of course, you can find a moronic Unix vendor which changes interfaces
every week. But there is no reason to see change of strlc*() interface
in BSD systems: however one don't like their teams, they respect common
sense and API compatibility.

>  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.

This is problem for all stuff which uses autoconf instead of pre-tested
bunch of per-platform configuration recipes. The count and meaning
of arguments in mmap(), setpgrp() and others may differ.
asprintf() isn't exception. If one uses autoconf, he should be ready.
If one uses per-platform recipes (for example, see sendmail and postfix),
he can avoid such inconsistenses simply.

> > 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.

I asked Kaz Kylheku about his position, please don't propose me
such way.;)) Of course, in every role where perl/python/... is more
adoptable to use, they should be preferred; and C strings brain-damaged
design isn't the last reason to do it. But, again, this is out of context.


/netch


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]