Fearing take it makes a longer discussion about "C as such" and "C
style":

On Fri, 2007-09-07 at 10:16 +0200, Gianni Costanzi wrote:
> Sorry for the empty email that I've sent before this one :(
> 
> I just wanted to say that in my opinion, it is more correct to say
> 
> strncpy(dest, src, sizeof(src))
> 
> if you want to copy the data pointed by src to the location pointed by
> dest.. You wanto to copy src, and so you give the size of src (you

Yes. But it is usually more robust to limit such things on the size of
the
destination (and if one checked that src is small enough for the
destination,
it doesn't matter anyways).
The current situation copies the interface name to some struct which is
basically
defined by the kernel - so if this doesn't fit, probably next to nothing
will
work anyways.
Actually this (interface name in that structs) is the only place where
"strncpy(3)"
is required to be used (and snprintf(3) would be wrong BTW).

> must already be sure that dest points to a buffer large enough to hold
> src data)..
> 
>       "If the destination string of a strcpy() is not large enough  (that  is,
>       if  the  programmer  was  stupid  or lazy, and failed to check the size
>       before copying) then anything might happen.  Overflowing  fixed  length
>       strings is a favorite cracker technique." - BUGS section of
> "man strncpy" :)

Basically ACK. That's the reason for me to use everywhere (except in
cases as
above) "snprintf(3)" - even if it seems ridiculous, needs an "int" more
on the
stack, etc.

> But this is just my opinion... furthermore, I almost always use
> sizeof(struct my_struct) if src is a pointer to a "struct my_struct"
> data structure.

And if someone changes the definition of the variable to "struct
other_struct"?
Of course one *should* check everything on such changes but we all are
human too.
But I believe more in the compiler and other tools to check BTW.

Yes, the other solution doesn't catch the case where one changes from
"struct foo x"
to "struct foo *x" (except if sizeof(structfoo) == 4) - so that is not
100% foolproof
either but I consider it the smaller problem (if only quantity-wise).

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services




