Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Nov 1998 15:01:48 +1100
From:      Bruce Evans <bde@zeta.org.au>
To:        archie@whistle.com, bde@zeta.org.au
Cc:        dillon@apollo.backplane.com, freebsd-current@FreeBSD.ORG, grog@lemis.com, rnordier@nordier.com
Subject:   Re: snprintf() in the kernel
Message-ID:  <199811250401.PAA17400@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>> strncpy() already takes a length arg.  Changing from strncpy() to
>> snprintf() just wastes space and time unless the value returned by
>> snprintf() is actually checked and cases where the string doesn't
>> fit are actually handled.
>
>Except when there needs to be a trailing NUL byte and the original
>code doesn't manually put one in the last buffer byte. For example,

Then the fix should usually be to put one in.

>> >    netatm/spans/spans_print.c
>> 
>> It's interesting that it doesn't just printf everything (using separate

>Yes, the code is technically correct, but figuring this out requires
>reverse engineering a bunch of function calls, etc. before you can
>conclude that there's no actual bug there. Why force a future
>programmer to have to rediscover that the buffers won't overflow?
>Why not make it obvious? This is not a bug fix but rather a
>maintainability fix, as are most of these..

We don't maintain HARP.  Its maintainers presumably have to worry about
snprintf() not being available on all supported platforms.

>> >    i386/ibcs2/ibcs2_stat.c
>> >    i386/ibcs2/ibcs2_xenix.c
>> >    i386/linux/linux_misc.c
>> 
>> These depend on a previous bzero() to zero out the buffer (and any padding
>> in the struct).  The strncpy()'s of course should have used sizeof() instead
>> of literal constants.  The explicit \0 termiation could have been avoided
>> in ibcs2_stat.c by subtracting 1 from the sizes.  This is already done in
>> ibcs2_xenix.c and linux_misc.c, but it is hard to see because sizeof() is 
>> not used and the subtraction is done at code-write time.
>
>Again, the code is technically correct but less than pleasant to look at
>and requires analysis and cross-checking to conclude that there's no
>actual bug.. yuck.

The faults in the code don't include using strncpy().

Bruce

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811250401.PAA17400>