Wireshark-bugs: [Wireshark-bugs] [Bug 2311] Wrong strncat usage in epan/dissectors/packet-gtp.c

Date: Fri, 29 Feb 2008 03:39:00 +0000 (GMT)
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2311


Guy Harris <guy@xxxxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         OS/Version|Linux                       |All
           Platform|PC                          |All
         Resolution|                            |FIXED




--- Comment #4 from Guy Harris <guy@xxxxxxxxxxxx>  2008-02-29 03:38:45 GMT ---
Yes, we should clean up our strncpy()/strncat() usage, using
g_strlcpy()/g_strlcat() or, in many cases, using routines that dynamically
allocate strings to remove fixed lengths entirely.

(I think strncpy() and strncat() were created to deal with a data type used in
some places in UN*X, namely strings with a maximum length where the string was
terminated either by the maximum length or a null character if the string was
less than the maximum length; that was used, as I remember, in places such as
the utmp and wtmp files.  I think that's why it does such a bad job of handling
strings with a maximum length that are always supposed to be null-terminated -
I don't think it was *intended* to handle that.)

However, in this *particular* case, we should clean up the code by not sticking
our fingers into the middle of the column information structure - that stuff
should probably be made opaque, to discourage that.  Perhaps when that code was
written, we didn't have col_prepend_fstr(), so it couldn't be implemented using
standard libwireshark routines, but we now have col_prepend_fstr(), as well as
col_append_str(), so we *can* do that using standard libwireshark routines.

I've checked in a change to do that.


-- 
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.