Tom Lane írta:
> Andrew Dunstan writes:
>
>> Boszormenyi Zoltan wrote:
>>
>>> Is it *really* a bug? I recalled a comment from my C teacher
>>> in '92 or '93 about this exact issue, that the prefix/postfix
>>> increment/decrement operators are executed in the
>>> statement in an implementat
Andrew Dunstan writes:
> Boszormenyi Zoltan wrote:
>> Is it *really* a bug? I recalled a comment from my C teacher
>> in '92 or '93 about this exact issue, that the prefix/postfix
>> increment/decrement operators are executed in the
>> statement in an implementation-defined order,
> Not if they
Boszormenyi Zoltan wrote:
Is it *really* a bug? I recalled a comment from my C teacher
in '92 or '93 about this exact issue, that the prefix/postfix
increment/decrement operators are executed in the
statement in an implementation-defined order,
Not if they come after a short-circuit oper
Boszormenyi Zoltan írta:
> Tom Lane írta:
>
>> Boszormenyi Zoltan writes:
>>
>>
>>> for (; length > 0 && ptr[--length] == 0xff;);
>>>
>>>
>>
>>
>>> I suspect that GCC does the "--length" after checking
>>> "length > 0" and before checking the "ptr[...] == 0xf
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> for (; length > 0 && ptr[--length] == 0xff;);
>>
>
>
>> I suspect that GCC does the "--length" after checking
>> "length > 0" and before checking the "ptr[...] == 0xff",
>> but HP CC does it before checking "length > 0".
>>
>
Tom Lane wrote:
Boszormenyi Zoltan writes:
for (; length > 0 && ptr[--length] == 0xff;);
I suspect that GCC does the "--length" after checking
"length > 0" and before checking the "ptr[...] == 0xff",
but HP CC does it before checking "length > 0".
If it does, that
Boszormenyi Zoltan writes:
> for (; length > 0 && ptr[--length] == 0xff;);
> I suspect that GCC does the "--length" after checking
> "length > 0" and before checking the "ptr[...] == 0xff",
> but HP CC does it before checking "length > 0".
If it does, that is *unquestionably* a bug in HP
Boszormenyi Zoltan írta:
> Hi,
>
> my question is that what platform were these
> functions developed and tested?
>
> We have come across a value that fails a NOT NULL
> constraint upon INSERT under HP-UX/IA64, but not
> under x86-64 Linux. The value in question is
> 1.9998 assigned to
Hi,
my question is that what platform were these
functions developed and tested?
We have come across a value that fails a NOT NULL
constraint upon INSERT under HP-UX/IA64, but not
under x86-64 Linux. The value in question is
1.9998 assigned to a "double" variable.
Under HP-UX/IA64, te
