Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #2213

Re: language design and Optimization techniques

Show all headers | View raw

On 2019-04-26, Martin Ward <martin@gkc.org.uk> wrote:
> On 25/04/19 20:58, David Brown wrote:
>> It is a serious mistake to mix up "defined behaviour" and "correct
>> behaviour".  Only defined behaviour can be correct, but you can't fix
>> incorrect code by making it defined behaviour.
>
> "Defined behaviour" *can* be "correct behaviour"
> "undefined behaviour" can *never* be correct and therefore
> must be avoided at all costs.

That is only right if we are talking about *absolutely* undefined
behavior.

The term "undefined behavior" in a programming language standrad isn't
absolute. It just refers to a way of using a language for which the
standard imposes no requirements.

Some undefined behaviors are used for providing documented extensions.

In C, all platforms-specific functions are essentially such an
extension.

Consider that if we write this program:

  int main(void)
  {
    extern int write(double);
    return write(3.14);
  }

We have not defined the external symbol "write" anywhere, and so
this will fail to link on many platforms. That failure is allowed
because of "undefined behavior".

Now if we compile this on a POSIX system, it almost certainly will link;
we get an executable which calls the POSIX write function with invalid,
incompatible arguments. The consequences of this are also consistent
with "undefined behavior".

There could be a platform where there is an int write(double), where
the program is just fine! Also allowed by undefined behavior.

The unescapable interpretation is that the use of platform libraries
constitutes the use of documented extensions that supplant undefined
behavior.

A program that uses a platform specific function, interpreted in a pure
standard context, can have any behavior whatsoever: failing to link,
crashing, or producing the expectd behavior. None of those behaviors is
specifically required, and the choice of behavior is not required to be
documented.

> You dismiss cases of security holes due to undefined behaviour
> as "just program bugs, because programmers didn't do the right thing".
> The C ANSI standard is over 500 pages long and includes 199
> different cases of undefined behaviour. A quick quiz:
> without referencing the standard, how many of the 199 cases
> of undefined behaviour can you list off the top of your head?
> Remember: a *good* programmer (one that you would describe
> as an engineer who knows what they are doing) must avoid
> all 199 cases of undefined behaviour in every line of code
> that they write.

Not all cases are potentially relevant to every line of code.

For instance, only one line of code in the program can commit
the error of "void main". That line "takes one for the team", so the
remaining lines face at most 198 threats. :)

Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: Optimization techniques Martin Ward <martin@gkc.org.uk> - 2019-04-26 19:46 +0100
  Re: language design and Optimization techniques Kaz Kylheku <847-115-0292@kylheku.com> - 2019-04-26 21:06 +0000
  Re: Optimization techniques and consistent results David Brown <david.brown@hesbynett.no> - 2019-04-29 16:31 +0200
  Re: Optimization techniques Martin Ward <martin@gkc.org.uk> - 2019-05-02 10:56 +0100
    Re: Optimization techniques Kaz Kylheku <847-115-0292@kylheku.com> - 2019-05-02 17:51 +0000

csiph-web