Re: [open-source] Re: Wish for 2002 ...

[Valentin Nechayev <netch at iv dot nn dot kiev dot ua>]

 Fri, Jan 11, 2002 at 11:36:27, torvalds (Linus Torvalds) wrote about "Re: [open-source] Re: Wish for 2002 ...": 

> 	static char *strdup2(const char *s1, const char *s2)
> 	{
> 		size_t l1 = strlen(s1);
> 		size_t l2 = strlen(s2);
> 		char * p = xmalloc(l1 + l2 + 1);
> 
> 		memcpy(p, s1, l1);
> 		memcpy(p+l1, s2, l2);
> 		p[ l1 + l2 ] = 0;
> 		return p;
> 	}

Q.E.D.: no strcpy/strcat here.

> which is simple, portable, efficient, readable and secure. And notice how
> strlcat/strlcpy doesn't give you _any_ of those.

And if you want concatenate three, four or more strings,
you will produce another and another variants of strdup${n}()?
Or simply call asprintf() with loss in efficiency, but quire more
advantage in human readability?
This your `simple, portable, efficient, readable and secure' approach
has one but sometimes the most important quality: it is too limited
to one particular case.

> Then you just replace your current crap with
> 
> 	p = strdup2(PROMPT, challenge);
> 
> and get it all over with.

I'm really surprised why which little code piece was discussed as it were
be the top of programming art.;))  It can be even calculated why
Paul Eggert printed the same this piece: it is most ugly in the whole code,
and it is the code where strlcat() is used only for paranoia, not for
real need. Lots another places, where strlcat() is really needed for
security even in environment of a crowd of coders smoking dirty grass
from gas station, were (specially?) omitted. Correct discussion
isn't proceeded with such methods.

Nobody, I hope, declare strlc*() as panacaea. They are ugly and can
be considered only as temporary stopper for dam hole; but, even for this
they are better than strcpy/strcat: they provide local (for one function
call) security and requires programmer to keep real buffer size
in sight.

> I will claim that the easiest way to improve security and reliability has
> _nothing_ to do with stupid functions like strlcat, and _everything_ to do
> with
> 
>  - readable, understandable, straightforward
>  - small, "obvious" functions that are clearly secure in themselves.
>
> Which are good things to have even if you don't work on security.
> 
> So how about it? Create your own small "strdup2()" instead of pushing
> crap on others.

Your requirements shall never be fulfilled while the C language exists,
this greatest diversion in whole IT industry history. Unless C were muted to
support reliable strings, at least similar to C++ std::string class,
programmers will use dangerous strcpy/strcat stuff and make errors in this use.
strlcpy/strlcat weren't, AFAIS, designed for experienced programmers which
always imagine program with full clearance; there are too few such
programmers. These functions were designed to be used in *real* world
where most programmers can't think clean and reliable due to lack
of education, problems in family, too expensive life, or any another
reason. They want to use crutches, and librarian's task is to provide
the same crutches average programmer wants. No matters that strlcpy() is
twice less efficient, but that matters it helps against bugs. But this
simple truth is too hard to be understood by gods in programming.

* Their circle is too narrow, they are too far from people.
                                                   [ V. Lenin ]


/netch