For now know.
Later when I add the newer versions of IOS I can change it
to work differently.
I have the exact same code but with the original definition of ett
and everything works fine, so it wasn't the code I added.
> -----Original Message-----
> From: Guy Harris [mailto:guy@xxxxxxxxxxxx]
> Sent: Monday, November 10, 2003 6:16 PM
> To: mlum@xxxxxxxxxxxxx
> Cc: ethereal-dev@xxxxxxxxxxxx
> Subject: Re: [Ethereal-dev] Portability patches
>
>
>
> On Nov 10, 2003, at 5:42 PM, Michael Lum wrote:
>
> > The malloc() change for the definition of ett does not appear to work.
> >
> > My last patch is good but the malloc/pointer stuff isn't.
> >
> > Ethereal will core:
> >
> >
> > ** ERROR **: file proto.c: line 2084 (proto_item_add_subtree):
> > assertion
> > failed: (idx >= 0 && idx < num_tree_types)
> > aborting...
> > Abort(coredump)
>
> It doesn't do so when I start a version built on Mac OS 10.3.
>
> Is this happening with the current CVS code, or code with some changes
> you've added?
>
> However, when looking at the code:
>
> it appears, from what Albert Chin said, that what's
> upsetting the HP
> compiler is the "?"/":" operator;
>
> the only places I see that being used in *that* context are the
> definitions of MAX_NUM_DTAP_MSG and MAX_NUM_DTAP_MSG;
>
> "size_t" is unsigned, so the first argument to
> "ANSI_A_MAX()", in both
> cases, should be >= 0 (and, in fact, as arrays can't be zero-length in
> ANSI C89, should be > 0);
>
> so we should be able to just define MAX_NUM_DTAP_MSG as
> NUM_IOS401_DTAP_MSG, define MAX_NUM_BSMAP_MSG as NUM_IOS401_BSMAP_MSG,
> and go back to the way it was.
>
> Is there any compelling reason to leave the "ANSI_A_MAX()" call in the
> definitions of MAX_NUM_DTAP_MSG or MAX_NUM_BSMAP_MSG?