GCC Undefined Behavior Sanitizer

via Digitalmars-d digitalmars-d at puremagic.com
Fri Oct 17 09:49:10 PDT 2014


On Friday, 17 October 2014 at 16:26:08 UTC, ketmar via 
Digitalmars-d wrote:
> i have nothing against this either. but i have alot against 
> "integral with arbitrary size" type.

Actually it makes a lot of sense to be able to reuse 16-bit 
library code on a 24-bit ALU. Like for loading a sound at 16-bit 
then process it at 24-bit.

> nope. if int is 32 but, and it's behavior is defined as 2's 
> complement
> 32-bit value, it doesn't matter what register size HW has. it's
> compiler task to make this int behave right.

And that will result in slow code.

>> Then again, that makes you a very careful programmer ;)
> that almost turned me to serial killer.

Yeah, IIRC I "cracked" it and put it on a diskette after a while…

> i don't buying that "we'll made that pretty soon" PR. first 
> they making
> it widespreaded, then i'll start caring, not vice versa.

C++ has a workgroup on transactional memory with expertise… So, 
how long can you wait with planning for the future before being 
hit by the train?

You need to be ahead of the big mover if you want to gain 
positions in multi-threading (which is the most important area 
that is up for grabs in system level programming these days).

> this is a misconception. "low level language" is not one that 
> pleases
> CPU down to bits and registers, it's about *conceptions*.
>

> for example, good high-level language doesn't need pointers, yet
> low-level one needs 'em.

Bad example. Low level languages need pointers because the 
hardware use 'em. If you have a non-standard memory model you 
need deal with different aspects of pointers too (like segments 
or bank switching).

If you cannot efficiently compute existing libraries on 24-bit, 
48-bit or 64-bit ALUs then the programming language is tied to a 
specific CPU. That is not good and it will have problems being 
viewed as a general system level programming language.

A system level language should not force you to be overly 
abstract in a manner that affects performance or restricts 
flexibility.


More information about the Digitalmars-d mailing list