On 4 February 2013 08:41, Jeremy Kajikawa jeremy.kajikawa@gmail.com wrote:
The behaviour in SmallTalk relies on the underlying framework which you state is C language and full of undefined behaviour...
That's not quite true. Smalltalk's behaviour is perfectly well defined, in terms of a stack machine. This PARTICULAR VM is built using Slang, a stripped down dialect of Smalltalk that can be mapped quite easily to C.
There is nothing in Smalltalk's definition about how you implement a virtual machine and, in fact, people have implemented a VM in PyPy, while others have run Smalltalk _directly_on_hardware_.
frank
Doesn't that make the SmallTalk environment Undefined Behavior as well by inheriting the UB from the C layer it builds on?
No.
Or is that just irrational F.U.D. in promotion of SmallTalk by detraction against C?
Yes.
frank
*both* languages are capable and leave defining behavior to the authoring programmer/coder/software-developer/...
Or at least that is my own understanding...
Belxjander
On Feb 4, 2013 5:32 PM, "Camillo Bruni" camillobruni@gmail.com wrote:
On 2013-02-04, at 08:49, Igor Stasenko siguctua@gmail.com wrote:
On 28 January 2013 23:07, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2013/1/28 Ken Causey ken@kencausey.com:
Eliot said:
Hmmm. Sorry to put you to this but what happens when you run the r2669, r2672 and r2673 VMs from http://www.mirandabanda.org/files/Cog/VM/? If these don't crash then it might be something to do with gcc 4.4.x. But I'd have to take a look, and time is tight right now... But if any of them do work could you use them for the interim?
Not a problem and thanks for the reply.
Well I started with 2673 and the tests are still running but it would have crashed by now if the same problem exists so it's looking like the gcc version is the issue. I will try earlier gcc versions and report back.
It's a little disheartening that in this day and age we are tickling gcc issues when the same version of gcc is used to build the kernel and thousands upon thousands of Debian binaries which (by and large anyway) seem to be fine.
Ken
And the answer would be: don't rely on UB (Undefined Behavior) Modern interpretation of the standards is that a compiler has a license to ignore UB in order to perform optimizations... This is because no one should rely on UB. Unfortunately, the underlying C language is full of UB, and the signed arithmetic model is particularly broken...
I doubt the thousands of packages have been working unchanged... They work with army of programmers maintaining the code and chasing the compiler warnings. As long as we ignore the warnings, we are in danger. As long as we have several hundreds warnings, there is no easy way to analyze their dangerosity...
I cannot agree more.
well you mute them, right?