Subject | Re: [Firebird-devel] Re: [ib-support] Current status of the bugs around isc4.gdb on fb1.0.2 |
---|---|
Author | Mark O'Donohue |
Post date | 2003-01-18T00:49:10Z |
Hi Ann
Ann W. Harrison wrote:
int, so the USHORT would be promoted to a full 4 bytes int, making
short sh = va_arg (ptr, USHORT);
the equivalent of :
short sh = va_arg (ptr, int);
perhaps that's a bit ambiguious, (ie which 2 bytes of the 4 did it get?)
The recommended way to do this is :
case 'c': /* char */
/* need a cast here since va_arg only
takes fully promoted types */
c = (char) va_arg(ap, int);
printf("char %c\n", c);
break;
It used to give a warning but with later versions of gcc now give an
error. While this might be nice since the ambiguity is rubbed in our
face - but it doesn't help when the old stuff "worked" :-).
However I also need to be carefuly, since to recompile this reversed
change I went back to gcc 2.91 from gcc 3.0.1 (3.0.1 refused to compile
the old form) - so it could still be a still library difference -
nothing a bit of simple testing won't reveal.
(I might in future confine myself to posts to fb-devel, till the bug fix
is done)
Cheers
Mark
Ann W. Harrison wrote:
> At 06:10 PM 1/17/2003 +1100, Mark O'Donohue wrote:But be careful in va_arg, anything shorter than an int is promoted to an
>
>> It was one of the :
>> - sh = va_arg (ptr, USHORT);
>> + /* sh = va_arg (ptr, USHORT); */
>> + sh = (USHORT) va_arg (ptr, int);
>>
>> changes in jrd/misc.c
>
>
> OK. That's not going to generate the same code - an int
> being generally four bytes and a USHORT two.
int, so the USHORT would be promoted to a full 4 bytes int, making
short sh = va_arg (ptr, USHORT);
the equivalent of :
short sh = va_arg (ptr, int);
perhaps that's a bit ambiguious, (ie which 2 bytes of the 4 did it get?)
The recommended way to do this is :
case 'c': /* char */
/* need a cast here since va_arg only
takes fully promoted types */
c = (char) va_arg(ap, int);
printf("char %c\n", c);
break;
It used to give a warning but with later versions of gcc now give an
error. While this might be nice since the ambiguity is rubbed in our
face - but it doesn't help when the old stuff "worked" :-).
However I also need to be carefuly, since to recompile this reversed
change I went back to gcc 2.91 from gcc 3.0.1 (3.0.1 refused to compile
the old form) - so it could still be a still library difference -
nothing a bit of simple testing won't reveal.
(I might in future confine myself to posts to fb-devel, till the bug fix
is done)
Cheers
Mark