On Wed, Dec 18, 2002 at 01:37:45PM -0500, Ronald Henderson wrote:
> Marting Regner and I need your desired coding fix based on discovering the
> cause of blank lines or garbage data at the end of the value that appears on
> the windows platform for LDAP and SIP protocols when values exceed the
> ITEM_LABEL_LENGTH limit. This behavior is different for the Linux platform.
What about the Solaris and FreeBSD platforms, on which I do most of my
Ethereal development? :-)
(I.e., you probably meant "UNIX platform" or "UN*X platform".)
> The C runtime libraries do not insert a termination character '\0' for the
> snprintf() and vsnprintf() functions if the value exceeds the size limit.
> These functions are found in the "proto.c" file.
Presumably meaning "used in the 'proto.c' file".
> A simple modification to force printing under windows
> for FT_STRING types is to change code in the function format_text(const
> guchar *string, int len) file strutil.c
>
> From:
> if (isprint(c)) {
>
> To:
> if (isprint(c) && (c < 128)) {
Or move the
#ifdef _WIN32
/* It appears that isprint() is not working well
* with gtk+'s text widget. By narrowing down what
* we print, the ascii portion of the hex display works.
* MSVCRT's isprint() returns true on values like 0xd2,
* which cause the GtkTextWidget to go wacko.
*
* (I.e., whilst non-ASCII characters are considered printable
* in the locale in which Ethereal is running - which they might
* well be, if, for example, the locale supports ISO Latin 1 -
* GTK+'s text widget on Windows doesn't seem to handle them
* correctly.)
*
* This is a quick fix for the symptom, not the
* underlying problem.
*/
#undef isprint
#define isprint(c) (c >= 0x20 && c <= 0x7f)
#endif
stuff out of "gtk/gtkglobals.h" and put it in a separate header, and
include that header in "strutil.c".
The long-term fix should probably be changes to better handle non-ASCII
characters, as per a recent discussion of FT_STRING issues and Unicode.
> Linux:
> ======
> For the linux platform the behavior for the snprintf() and vsnprintf() are
> the similar as far as the null terminating character is concern (i.e. there
> will be none if the value exceeds the size limit). But what is different is
> the non-printable character are shown as garbage characters, therefore no
> blank lines.
That's really a Windows vs. UNIX+X, not a Windows vs. Linux
difference; the GTK+ 1.2[.x] behavior atop X may be different from the
GTK+ 1.3[.x] behavior atop Windows.
> NOTES
> The glibc implementation of the functions snprintf and vsnprintf
> conforms to the C99 standard, i.e., behaves as described above, since
> glibc version 2.1. Until glibc 2.0.6 they would return -1 when the output
> was truncated.
...which is an issue that Ethereal works around, so we shouldn't assume
it returns the number of characters that would have been written, but we
can assume that if it returns -1 it's the older version.
There may be other implementations that behave that way.
> Questions:
> =========
> How would you like the fix to be in proto.c?
>
> 1) Does this check have to be corrected for every instance of snprintf() and
> vsnprintf() or just for proto values that make since (i.e. FT_STRING)?
Every place in Ethereal that uses "snprintf()" or "vsnprintf()" should
be checked to make sure that either
1) it null-terminates the buffer
or
2) it doesn't require the buffer to be null-terminated.
Not all uses of "snprintf()" and "vsnprintf()" are in "proto.c"; the
ones that aren't should be audited as well.
> 2) From what I see the check needs to be for return values of -1 or size
> greater than or equal to ITEM_LABEL_LENGTH
Yes, you have to check for both.
> 3) Should a compiler directive be used here for a Windows build vs a Unix
> build (i.e. #ifdef _WIN32)?
See above. The only issue is the behavior of Windows GTK+ for non-ASCII
characters; that's probably a consequence of GTK+ 1.2[.x] assuming
strings are in whatever encoding is appropriate for the font being used
(unfortunately, I don't know whether you can get GTK+ to tell you what
the encoding is, or even whether it's a 1-byte or 2-byte encoding) and
GTK+ 1.3[.x] (and 2.x) assuming strings are UTF-8.
