Guy, Joerg,
thank you for giving the correct hint. Changing the three '16' to
'17' fixes the problem on my machine.
If this is also OK on other platforms the following patch can be
applied.
Index: epan/to_str.c
===================================================================
RCS file: /usr/local/cvsroot/ethereal/epan/to_str.c,v
retrieving revision 1.20
diff -r1.20 to_str.c
88c88
< static const gchar hex_digits[16] = "0123456789abcdef";
---
> static const gchar hex_digits[17] = "0123456789abcdef";
217c217
< static const gchar hex_digits[16] = "0123456789ABCDEF";
---
> static const gchar hex_digits[17] = "0123456789ABCDEF";
574c574
< static const gchar hex_digits[16] = "0123456789abcdef";
---
> static const gchar hex_digits[17] = "0123456789abcdef";
Best regards
Michael
On Monday, Dec 9, 2002, at 05:18 Europe/Berlin, Guy Harris wrote:
On Mon, Dec 09, 2002 at 01:16:36AM +0100, Michael Tuexen wrote:
ld: epan/libethereal.a(to_str.o) literal C string section
(__TEXT,__cstring) does not end with a '\0'
A new routine "fc_to_str_buf()" was added to "to_str.c" in 0.9.8, and
it
declares a "static const gchar" array of 16 elements, initialized to a
string "0123456789abcdef"; I'd have to see my ANSI C standard, which is
at work, to see whether
static const gchar hex_digits[16] = "0123456789abcdef";
is illegal C (because "0123456789abcdef", as a string constant, is 17
bytes long, with the 17th byte being the terminating '\0'), so that
Apple can't be blamed for whining about that, or whether it's legal C
and Apple's C compiler should just shut up and stop whining. (I
suspect
the latter is the case - an array of "char" is *NOT* necessarily a C
string.)
