[Vm-dev] 3 Bugs in LargeInteger primitives

[Nicolas Cellier]

Originally, C was very close to machine instructions and was conceived
as a generic assembler.
But it's more and more distant and becoming abstract.

Unfortunately, the abstract arithmetic model is completely broken with
UB: it's un-reliable.
So what does this kind of abstraction serves?
Really, it makes me wonder...

If portable C code becomes both long and inefficient, I guess that
cost of maintaining assembler for some part that we know are broken is
an option indeed.

I also see that Andreas had a hard time with slang, some intermediate
operations being cast to uint32 instead of int64, he finally had to
use many cCode: hacks... Going both thru slang and C intermediate
sounds like too much work and too few safety for implementation basic
arithmetic (obviously we didn't and we can't easily model broken C
behaviour in Slang, it's too complex !).

Nicolas

2012/8/29 Stefan Marr <smalltalk at stefan-marr.de>:
>
> Hi Nicolas:
>
> On 29 Aug 2012, at 12:18, Nicolas Cellier wrote:
>
>>
>> Beside these bugs, when I read the code, I'm quite sure it's a nest of
>> future bugs because there are many other attempts to catch overflow in
>> post-condition (like testing that addition of two positive is negative
>> when an underflow occurs) that technically rely on explicitely
>> Undefined Behaviour (UB).
>
> I guess http://forum.world.st/Is-bytecodePrimMultiply-correct-td3869580.html
> is related too.
> I am not sure whether that got changed in the VMs, but sounds very much like the same kind of problem. (undefined behavior and overflows)
>
> Since C is undefined in that regard, what are the options?
> Hand-crafted assembly for all relevant platforms?
> Are there libraries that abstract from these things?
>
> I think Clang has a compiler switch to warn at compile-time, or trigger a runtime warning/error for these issues with undefined behavior. That might help for a thorough sweep through the code.
>
> Best regards
> Stefan
>
>
> --
> Stefan Marr
> Software Languages Lab
> Vrije Universiteit Brussel
> Pleinlaan 2 / B-1050 Brussels / Belgium
> http://soft.vub.ac.be/~smarr
> Phone: +32 2 629 2974
> Fax:   +32 2 629 3525
>