lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Interesting article : it finally shows that compilers are made by people that are interested only in compilers and prure performance, and don't even care about making it useful for any language.

Now if C99 allows this, then C99 is not a language defined for programmers, jsut for the interests of compiler makers. It just kills the language and makes it completely useless (and malicious) to any one: programmers, and final users (which are not even given any right to know what is in the program they buy or use, these programs are also best to categorize are malwares).

In summary, C is a malware to eradicate, unless it is implemented by replacing all undefined behaviors from the so called "standard" by defined behavior.

For the simple case of (INT_MAX+1), it can be deterministic on all platform by saying its result must be INT_MIN (disregard the concept of 2-complements which implies a binary representation). And on most machines, this is what the native opcodes do, so it has no cost. But compilers cannot misbehave and pretend this is undefined behavior allowing them to *silently* remove instructions and treating them as no-ops (ignoring completely the explicit developer's desires, as if the developer was stupid and only the compiler knows better what to do: at least the compiler should emit a warning that programmers can see, and the compiler and language specification must provide a way to avoid this situation).

As well (INT_MIN-1) must be INT_MAX.

For (1 << n), it must be defined (as 0) if 2^n is larger than INT_MAX (yes it implies a cost for compilers: on x86, the value of n is silently masked by considering only the 5 lowest bits of n for 32 bit operations, or 6 lowest bits for 64-bit operations, this only depends on the opcode used, i.e. the bitsize of the specified register for the SHL instruction). But in the C language, these considerations about native opcodes and native register sizes is not relevant, and it's up to compilers to allocate the proper registers and generate the instructions according to the language specifications, adding additional code where needed to get the expected result, so compilers should then emit an AND masking instruction before emitting the SHL.

What is the real cost of these check ? None. C is a now very old language, the minor performance costs was completely erased by massive gains of performance: the small impact it has is temporary and cancels rapidly.

Are compiler makers serious ? Don't they care about the huge costs they generate worldwide and the massive security attacks we see today ?

Those compiler makers should be fired and given NO vote to language standardizers: fire them from all standard bodies, don't hear what they want to pass !

Placing "undefined behavior" in any language standard is simply stupid (and lazy !). There may be cases where this was unexpectedly forgotten, but the best to do is to update the standard, look at existing "compliant" implementations and study what will be the best defined behavior to integrate in the standard. That's what is done (hopefully) for Java or ECMAscript/_javascript_ (which is now eradicating Typescript completely). Doing that will possibly make some existing "compliant" implementations suddenly non-compliant.

But at least developers will get an opportunity to update their compiler tools with more recent versions: even if the generated code is not modified (for compatibiliy reason), at least the new compilers will emit trackable warnings that will allow developers to fix their source code to behave as they expected once compiled and tested by them, and then run by final users that must be able to trust the developers.

For now the C standard is not made for any one. Its goals are stupid. The whole team of this standard body (most of them from ANSI) should be fired (or another standard body should take ove the goal of redefining it). Everyone in the computing industry will be interested and now every one in the world uses computers and are interested: this goal is no longer technical, it has become a fundamental human right to absolutely preserve, but voluntarily ignored by the existing standard body which behaves like devil.

Le dim. 12 mai 2019 à 12:41, Lorenzo Donati <lorenzodonatibz@tiscali.it> a écrit :
On 12/05/2019 12:08, Philippe Verdy wrote:
> Le dim. 12 mai 2019 à 07:38, Andrew Gierth <andrew@tao11.riddles.org.uk> a
> écrit :
>
>>>>>>> "Philippe" == Philippe Verdy <verdy_p@wanadoo.fr> writes:
>>
>>  >> fprintf(stderr,"n=%lli x=%llx
>>  >> <≤=≥>:%i%i%i%i%i\n",n,n,n<0,n<=0,n==0,n>=0,n>0);
>>  >> if (n<0) n=-n;
>>  >> fprintf(stderr,"n=%lli x=%llx
>>  >> <≤=≥>:%i%i%i%i%i\n",n,n,n<0,n<=0,n==0,n>=0,n>0);
>>  >>
>>  >> produces (GNU compiler):
>>  >>
>>  >> n=-9223372036854775808 x=8000000000000000  <≤=≥>:11000
>>  >> n=-9223372036854775808 x=8000000000000000  <≤=≥>:01010
>>
>>  Philippe> What you show here is a bug of the C compiler in its
>>  Philippe> optimizer
>>
>> Possibly unfortunately, this is not a bug. The program invokes undefined
>> behavior when it does n=-n on the the value shown; the compiler is
>> entitled to produce any output at all as a result.
>>
>> In this case it's fairly obvious what happened: after seeing the line
>>
>> if (n<0) n=-n;
>>
>> the compiler is entitled to assume that n>=0 is true regardless of the
>> prior value of n, since only undefined behavior could cause that not to
>> be the case and the compiler is allowed to assume that undefined
>> behavior never occurs. So in the second fprintf, the compiler can
>> optimize (n>=0) to a constant 1, and (n<0) to a constant 0, while still
>> computing the remaining tests.
>>
>
> Such compiler assumption is wrong and it's clearly a bug in its optimizer ,
> trying to infer constant values from code whose evaluation is clearly not
> constant here, that line does not mean that the result in n is necessarily
> positive. so it cannot assume that n>=0 after this line (even if C
> indicates that the result is undefined, then the further tests of n<0 and
> n>=0 must still be computed: an undefined value has no *constant* sign).
>


[snip]

"the result is undefined..." and "... and undefined value..."



Sorry, but it seems that you are not aware of what "undefined behavior"
(UB) means in C. There is no "undefined result" and neither "undefined
value".

That jargon is not generic CS jargon, but it is a concept mandated by
the standard.

Basically, once your program triggers UB even in a single spot in a
gazillion lines of code, the whole gazillion lines are garbage.

Quoting from section 3.4.3 of C99 draft standard (N1256), emphasis mine:

==========================================================
3.4.3
1 undefined behavior

behavior, upon use of a nonportable or erroneous program construct or of
erroneous data, for which this International Standard imposes /no
requirements/

2
NOTE Possible undefined behavior ranges from /ignoring the situation
completely/ with /unpredictable results/, to behaving during translation
or program execution in a documented manner characteristic of the
environment (with or without the issuance of a diagnostic message), to
terminating a translation or execution (with the issuance of a
diagnostic message).

3
EXAMPLE An example of undefined behavior is the behavior on integer
overflow.

==========================================================

So there is no requirement for any conforming implementation to do
anything sensible when UB is invoked.

Note also that it is not /the value/ that it is undefined. Any program
construct that invokes undefined behavior renders /the whole program/
garbage, from the POV of a conforming implementation.

To stress that ANYTHING could happen, it is a common joke among C
programmers to say that if you trigger undefined behavior you get
"demons coming out of your nose", usually abbreviated to "you get nasal
demons".

An interesting set of articles from the blog of John Regehr (Professor
of Computer Science, University of Utah, USA) that may shed some light
on the rationale behind UB:

https://blog.regehr.org/archives/213


Cheers!

-- Lorenzo