GCC Undefined Behavior Sanitizer

[ketmar via Digitalmars-d]

On Fri, 17 Oct 2014 15:58:02 +0000
via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> On Friday, 17 October 2014 at 15:17:12 UTC, ketmar via 
> Digitalmars-d wrote:
> > it's good. but this not justifies the decision to make 2's 
> > complement
> > overflow undefined.
> If you want a circular type, then call it something to that 
> effect. Not uint or int. Call it bits or wrapint.
it would be nice. but i'm still against "integral wrapping is
undefined". define it! either specify the result, or force program to
crash.

> > yes. what's wrong with using long/ulong when you need 64 bits?
> What is wrong and arbitrary is promoting to 32-bits by default.
64-bit ARMs aren't so widespread yet. oh, wait, are we talking about
x86-compatible CPUs only? but why?

> > did you noticed long/ulong types in D specs? and reserved 
> > 'cent' type
> > for that matter?
> If you want fixed width, make it part of the name: i8, i16, i24, 
> i32, i64…
i have nothing against this either. but i have alot against "integral
with arbitrary size" type.

> Seriously, if you are going to stick to fixed register sizes you 
> have to support 24 bit and other common register sizes too. 
> Otherwise you'll get 24bit wrapping 32bit ints.
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.

> > i was trying to use C for Z80, and that wasn't a huge success 
> > that days.
> How did you manage to compile with it? ;-)
it was... painful. even with disk drive. having only 64KB of memory
(actually, only 48K free for use) doesn't help much too.

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

> > around. let's talk about this when we'll have widespreaded HW 
> > with this feature.
> That goes real fast, because is probably cheaper to have it built 
> into all CPUs of the same generation and just disable it on the 
> ones that have to be sold cheap because they are slow/market 
> demand.
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.

> > and i must spend time to make some silicon crap happy, again?
> 
> If you want a high level language, no.
> 
> If you want a system level language, yes!!!!!!!!!!
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. good high-level language makes alot of checks
automatically (range checking, overflow checking and so on), goot
low-level language allows programmer to control what will be checked
and how. good high-level language can transparently use bigints on
overflow, good low-level language has clearly defined semantic of
integer overflow and defined sizes for integral types. and so on.

"going low-level" is not about pleasing CPU (it's not assembler), it's
about writing "low-level code" -- one with pointers, manual checks and
such.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141017/4dabaac7/attachment.sig>