[Vm-dev] about generating long long min literal...

[Andres Valloud]

How about -1LL << 63?

On 3/13/15 16:47 , Nicolas Cellier wrote:
>
>
>
>
> Ah, ah, it's not a gcc bug, it's just one another C pitfall...
>
> if you want to translate in C the literal -16r8000000000000000 which is
> (1 << 63) negated, or the LLONG_MIN constant, you have to be clever.
>
> The most simple thing like generating -0x8000000000000000LL just won't work.
>
> Indeed, the C parser interprets this as two tokens, the negative sign,
> and a positive integer literal 0x8000000000000000LL. Oh, but wait, this
> is greater than LLONG_MAX and does not fit in a signed long long. Thus
> the clever compiler thinks it has to promote this constant to an
> unsigned long long, no matter what you tried to tell him.
>
> Fortunately, due to its infinite compassion with poor humans, the C
> compiler tells you about this bad trick with a warning (something like
> <the constant is so huge that it is unsigned>).
>
> So how should you generate? Easy, it's just (-0x7fffffffffffffffLL-1)
> for example.
>
> Yeah, but that means that I have to try a third attempt for generating
> the C literals... Find attached.
>
> I love C.
>
> Nicolas
>
>
> -------------------------------
>
> Why didn't we fall on this edge cases before? Luck?
> I wrote a primitiveByteCodeMultiply not subject to undefined behavior of
> integer overflow and thus portable like described at
> https://www.securecoding.cert.org/confluence/display/c/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow
>
> Of course, a jump on overflow as generated by cog is much
> simpler/efficient :)
>
> All the code is extracted from my musing with 32-bit digit LargeInt
> which currently work well in 32bits cog V3 & spur and is located at
> MCHttpRepository
>      location: 'http://smalltalkhub.com/mc/nice/NiceVMExperiments/main'
>      user: ''
>      password: ''
>
> I could not compile a 64 bits squeak.stack.spur; my iOS SDK is too far
> behind it seems...
> I'll try on a linux virtual box.
>