Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: RE: [Ethereal-dev] Problems compiling ethereal 0.9.8 under MacOS X

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Esh, Andrew" <AEsh@xxxxxxxxxxx>
Date: Mon, 9 Dec 2002 08:25:38 -0600
Title: RE: [Ethereal-dev] Problems compiling ethereal 0.9.8 under MacOS X

The more correct initialization (and the one which is probably intended) is this:

        static const gchar hex_digits[16] = '0', '1', '2', '3', '4', '5', '6', '7',
                                                        '8', '9', 'a', 'b', 'c', 'd', 'e', 'f';

-----Original Message-----
From: Guy Harris [mailto:gharris@xxxxxxxxx]
Sent: Sunday, December 08, 2002 10:18 PM
To: Michael Tuexen
Cc: ethereal-dev@xxxxxxxxxxxx
Subject: Re: [Ethereal-dev] Problems compiling ethereal 0.9.8 under
MacOS X


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.)
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev