[SystemSafety] Critical systems Linux

[Olivier Andrieu]

On Fri, Nov 23, 2018 at 3:57 AM Olwen Morgan olwen at phaedsys.com
<http://mailto:olwen@phaedsys.com> wrote:


> With C there can never be the solidity of technical guarantee that one
> might like. You might recall my earlier-posted piece of C mischief:
>
> #include <stdio.h>
>
> void PrintEvalOrder( int p1, int p2, int p3)
> {
>      printf("\np1, p2, p3 evaluated in order: p%i, p%i, p%i\n", p1, p2,
> p3);
>      return;
> }
>
> int main(void)
> {
>      int i = 0;
>
>      /* next line tests order of eval. of args to a function call */
>
>      PrintEvalOrder((++i), (++i), (++i));
>
>      return 0;
> }
>
> Compiled under gcc version 5 and then run, this outputs: "p1, p2, p3
> evaluated in order: p3, p3, p3" - thereby revealing over-agressive
> optimisation even in a simple program.
>
> One hopes that CCG steers clear of such problems but I'd challenge
> anyone to give a rock-solid proof that that is the case.
>
I’m not sure why you’re making this about the compilers. This program has
unequivocally an undefined behavior, so, whatever a compiler does, it’s not
wrong.

Clang doesn’t even require an explicit warning option to point it out:

$ clang se.c
se.c:14:19: warning: multiple unsequenced modifications to 'i' [-Wunsequenced]
  PrintEvalOrder((++i), (++i), (++i));
                  ^      ~~1 warning generated.



—
Olivier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20181123/0751a0b2/attachment-0001.html>