[OPEN-ILS-DEV] Re: PATCH: bzero is deprecated and unnecessary

[Dan Scott]

On 28/09/2007, Dan Scott <denials at gmail.com> wrote:
> Hi:
>
> snprintf is defined to print a maximum number of characters into a
> string, and guarantees to NIL-terminate the string.
>
> The following patch corrects several situations where a string was
> defined with 256 characters, but snprintf was called with only 255
> characters, meaning that the 256th character would never be reached.
> Given that the call to snprintf was preceded by bzero (a deprecated
> method of initializing all of the contents of a given string to NIL),
> it seems likely that snprintf's NIL-terminating behaviour was
> overlooked or forgotten about.
>
> As bzero is deprecated, this patch removes calls to bzero that are
> followed by snprintf calls to the same string; the maximum number of
> characters specified to snprintf has been corrected, as well.
>
> I think this is trivial enough not to require a DCO. Let me know if
> you feel otherwise.
>

Replying to myself because I slept on this a while longer...

The attached patch replaces the first patch in the thread. In the
attached patch, I:

a) replace bzero calls (bzero is deprecated) with calls to memset. I'm
initializing the memory to '\0', feel free to change that to 0 if you
prefer.

b) replace, as much as possible, static lengths in memset & snprintf
calls with sizeof calls instead; this way, if we decide to change the
length of a given string, we only have to update the value in one
place. So instead of:

char buf[256];
memset(buf, '\0', 256);
snprintf(buf, 256, ...

we use:

char buf[256];
memset(buf, '\0', sizeof(buf));
snprintf(bug, sizeof(buf), ...

c) removed calls to bzero() or memset() when the variable that was
being initialized is immediately being filled via snprintf() --
snprintf() guarantees that the string will be terminated with NIL.

I'm sending this to the list rather than just committing it, because
it's been a few years since I've exercised my C skills in any
significant way and I would appreciate a once-over from others (like
Scott!).

Would we be interested in migrating to safer functions like strlcpy
and strlcat in the future? This wouldn't affect the Evergreen code
much, but a quick grep over the OpenSRF code suggests that there is
enough usage that we could benefit from that. David Wheeler wrote
about strlcat / strlcpy in his Secure Programming for Linux HOWTO
(http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/library-c.html)
and I have some positive experiences from using them in the ibm_db2
PHP extension. I can pull together a patch for OpenSRF to migrate to
these functions in fairly quick order, if there is interest.

-- 
Dan Scott
Laurentian University
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oils_mem2.patch
Type: text/x-patch
Size: 5377 bytes
Desc: not available
Url : http://list.georgialibraries.org/pipermail/open-ils-dev/attachments/20070929/8a3ae977/oils_mem2-0001.bin