GCC Undefined Behavior Sanitizer

[ketmar via Digitalmars-d]

On Fri, 17 Oct 2014 16:49:10 +0000
via Digitalmars-d <digitalmars-d at puremagic.com> 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.
and this is perfectly doable with fixed-size ints. just use 16-bit
library when you can and write new code when you can't.

> > 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.
i prefer slow code over incorrect code. if i'll find that some code is
a real bottleneck (using profiler, of course, almost noone can make a
right guess here ;-), i'll write arch-dependant assembler part to
replace slow code. but i prefer first to get it working after
recompiling, and then starting to optimize. what i don't want is to
think each time "what if int will have different size here?" that's why
i'm using types from stdint.h in my C code instead of just "int",
"long" and so on.

> > 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?
indefinitely long if language guarantees that my existing code will
continue to work as expected.

> 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).
i don't care about positions. what i care about is language with
defined behavior. besides, threads sux. ;-)

anyway, it's not hard to add "transaction {}" block (from the language
design POV, not from the implementor's POV). ;-)

> > 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.
i really can't imagine hardware without pointers.

> If you have a non-standard memory model you 
> need deal with different aspects of pointers too (like segments 
> or bank switching).
this must be accessible, but hidden from me unless i explicitly ask
about gory details.

> 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.
are you saying that 32-bit operations on 64-bit CPUs sux? than those
CPUs sux. throw 'em away. besides, having guaranteed and well-defined
integer sizes and overflow values is what making using such libs on
different architectures possible. what *really* ties code to CPU is
"int size depends of host CPU", "overflow result depends of host CPU"
and other such things.

> That is not good and it will have problems being 
> viewed as a general system level programming language.
nope. this is the problem of HW designers and compiler writers, not
language problem. i still can't understand why i must write my code to
please C compiler. weren't compilers invented to please *me*? i'm not
going to serve the servants.

> A system level language should not force you to be overly 
> abstract in a manner that affects performance or restricts 
> flexibility.
system level language must provide ability to go to "CPU level" if
programmer want that, but it *must* abstract away unnecessary details
by default. it's way easier to have not superefficient, but working
code first and continually refine it than trying to write it the hard
way from the start.
-------------- 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/0695f105/attachment.sig>