On Mon, 6 Jun 2016 20:12:19 +0200
k0ga_AT_shike2.com wrote:
Hey Roberto,
> What happens if you pass an incorrect size to strlcpy?. Please,
> stop of saying stupid things.
well, you don't pass invalid sizes to strlcpy. It's like if I
asked: Robert, what happens if I pass an invalid path to
unlink()? Huh, see, your world is crumbling into pieces.
> if (strlcpy(dst, src, nsrc) >= nsrc)
> error();
>
> is equal to:
>
> if (nsrc >= ndst)
> error();
> memcpy(dst, src, nsrc);
Nope, it's not. Keep in mind strlcpy fills the rest
of the memory area with 0's.
Also, I suspect you have not understood strlcpy()
at all. Read the manpage!
The size-argument of strlcpy is wrt to the size of
the _destination_, not the _source_.
Your example also hides the fact that "nsrc" has to
be first determined with strlen().
> but the code with strlcpy is slower and not portable.
I give you a beer at the next slcon if you can show me
a solution which does the same as strlcpy and is faster.
> There is a reason why after 16 years strlcpy is not in any
> standard, no C11, no POSIX, and it is because it sucks a lot.
Well, this is up for debate. I respect your opinion though.
> From my point of view the worst thing is that people believe
> that using strlcpy the code magically becomes secure, and this
> is a totally false security sensation. You have to check the
> return code, and it means that the code is totally equivalent
> to an explicit if. Look for example this case:
>
> deluser(strlcpy(dst, "user15", 4));
>
> Since you are not checking any return code there you are not
> deleting the correct user, and this kind of attacks can be very
> easy of attack, more easier than stack overflow.
Yes, this is a very good point. However, if you used strncpy,
the string would not even be terminated in case of an overflow.
It's funny to see how people wage holy war between strlcpy and
strncpy only to realize that of the two strlcpy is the safer
one.
Now, of course, you have to check the return value.
> In a previous mail you said that one of the reasons of using
> strlcpy was to avoid problems in the future due to modifications
> in the code. Did you think about it before writing it?. You
> can say that of _ANY_ operation in C, mainly with pointers and
> indexes, but strlcpy can not help at all in a situation like this:
>
>
> #define LENA 5
> #define LENB 6
>
> char sa[LENB];
>
> f(sa);
>
> f(char s[LENB])
> {
> strlcpy(s, "This is a very long string", LENB);
> }
>
> and now you have this patch:
>
> - char sa[LENB];
> + char sa[LENA];
>
> Do you see? strlcpy didn't help at all, and due to the
> false security sensation the programmer didn't dig to
> see all the side effects of changing the size of sa.
> C is a very low level language, and it is a language
> without support for strings, and the only way of writting
> correct code is to be very carefull and before doing any
> change check everything, and look for all the possible
> errors due to your change.
You cannot possibly check these things by yourself. What
strlcpy does is give you an insurance in case there is an
overflow that the program doesn't pass pointers to
unterminated strings around. Of course you have to check
the return value anyway.
I don't know why you are always riding the same horse
here given that:
1) dwm used strcpy (!)
2) dwm used _unchecked_ strncpy (!)
so you definitely should calm down a bit here.
> And of course, strlcpy is also totally useless because
> you can do the same work with snprintf.
I'm not sure if people want to involve the complex
mechanics of the *printf functions to do simple string
copying. You have to agree that on a decision between
strncpy and strlcpy, strncpy wins, no matter the context.
Of course, to use strlcpy safely, you have to check the
return code, because truncation is also yielding garbage.
However, at least this garbage won't blow up in your
face.
> PD: I don't want to begin a flame war, but please, stop
> of being a fan boy and think for yourself, try to find
> the strong points and what is propaganda.
Maybe you should evaluate your position a bit better
before going all grandpa here on this ml.
Your first code example is embarassing and shows that
despite your high skill in C you seem to be fighting
the wrong war here.
Cheers
FRIGN
--
FRIGN <dev_AT_frign.de>
Received on Mon Jun 06 2016 - 20:50:31 CEST