article : undefined behavior and the purpose of C

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

article : undefined behavior and the purpose of C

Mayuresh Kathe-2
Don't know if this has been discussed here before, but I found the
following excerpt from the article at
http://www.yodaiken.com/2018/12/31/undefined-behavior-and-the-purpose-of-c/ 
unnerving;
... often the writers of the ISO C Standard have thrown up their hands
and labeled the effects of non-portable and potentially non-portable
operations "undefined behavior" for which they provided only a fuzzy
guideline.  Unfortunately, the managers of the gcc and clang C compilers
have increasingly ignored the guideline and ignored well-established
well-understood practice, producing  often bizarre and dangerous results
...

Reply | Threaded
Open this post in threaded view
|

Re: article : undefined behavior and the purpose of C

Janne Johansson-3
Den tors 17 jan. 2019 kl 14:05 skrev Mayuresh Kathe <[hidden email]>:

>
> Don't know if this has been discussed here before, but I found the
> following excerpt from the article at
> http://www.yodaiken.com/2018/12/31/undefined-behavior-and-the-purpose-of-c/
> unnerving;
> ... often the writers of the ISO C Standard have thrown up their hands
> and labeled the effects of non-portable and potentially non-portable
> operations "undefined behavior" for which they provided only a fuzzy
> guideline.  Unfortunately, the managers of the gcc and clang C compilers
> have increasingly ignored the guideline and ignored well-established
> well-understood practice, producing  often bizarre and dangerous results
> ...
>

This came up before clang replaced gcc on certain arches:

https://marc.info/?l=openbsd-misc&m=137530560232232


--
May the most significant bit of your life be positive.

Reply | Threaded
Open this post in threaded view
|

Re: article : undefined behavior and the purpose of C

Raul Miller
In reply to this post by Mayuresh Kathe-2
Perhaps worth noting that a lot of this gcc quirkiness (and, via peer
pressure, clang quirkiness) was spawned in response to overly brittle
copyright laws and enforcement. (The expiration times have been
extended excessively to satisfy the likes of Disney, and the
enforcement seems to necessarily be focussed on stupid issues and most
people tend to be uninformed about the nature and character of the
laws and issues.)

To avoid the specter of copyright being enforced on computer software
(where the code tends to closely follow the spec), the gcc maintainers
(fsf and whoever else rms managed to recruit to that cause). adopted a
deliberate policy of extending and reinterpreting the specifications
and standards. As noted in that writeup, the consequences have not
always been good (and some pruning is probably warranted).

Fortunately, OpenBSD takes a more deliberate approach and this can
help temper some of that silliness (in part, through peer pressure).

That said, the laws themselves are a motivation here. In its current
form, copyright law has been overly hostile to industry and coding in
some ways, and presumably overly tolerant in some other ways (because
people have limited time and attention). The open source community has
been one successful workaround for this state of affairs. But the
"undefined behavior" sillinesses are one kind of example of where the
community misleads. Another successful workaround, in industry, has
been to offload manufacturing to China (which has not agreed to these
laws). But that introduces language barriers and other problems (which
are out of scope for this mailing list). Anyways, it seems like
industry should be demanding laws which enable it to get its work
done, but this isn't a subject suitable for polite conversation.

I wish I had a good answer here, but I don't...

That said, ... for now at least, focusing on practical issues hasn't
stopped being essential.

Responses to this message should go to me and not the list.

Thanks,

--
Raul


On Thu, Jan 17, 2019 at 8:07 AM Mayuresh Kathe <[hidden email]> wrote:

>
> Don't know if this has been discussed here before, but I found the
> following excerpt from the article at
> http://www.yodaiken.com/2018/12/31/undefined-behavior-and-the-purpose-of-c/
> unnerving;
> ... often the writers of the ISO C Standard have thrown up their hands
> and labeled the effects of non-portable and potentially non-portable
> operations "undefined behavior" for which they provided only a fuzzy
> guideline.  Unfortunately, the managers of the gcc and clang C compilers
> have increasingly ignored the guideline and ignored well-established
> well-understood practice, producing  often bizarre and dangerous results
> ...
>

Reply | Threaded
Open this post in threaded view
|

Re: article : undefined behavior and the purpose of C

Theo de Raadt-2
in the fiction of your mind

> Perhaps worth noting that a lot of this gcc quirkiness (and, via peer
> pressure, clang quirkiness) was spawned in response to overly brittle
> copyright laws and enforcement. (The expiration times have been
> extended excessively to satisfy the likes of Disney, and the
> enforcement seems to necessarily be focussed on stupid issues and most
> people tend to be uninformed about the nature and character of the
> laws and issues.)
>
> To avoid the specter of copyright being enforced on computer software
> (where the code tends to closely follow the spec), the gcc maintainers
> (fsf and whoever else rms managed to recruit to that cause). adopted a
> deliberate policy of extending and reinterpreting the specifications
> and standards. As noted in that writeup, the consequences have not
> always been good (and some pruning is probably warranted).
>
> Fortunately, OpenBSD takes a more deliberate approach and this can
> help temper some of that silliness (in part, through peer pressure).
>
> That said, the laws themselves are a motivation here. In its current
> form, copyright law has been overly hostile to industry and coding in
> some ways, and presumably overly tolerant in some other ways (because
> people have limited time and attention). The open source community has
> been one successful workaround for this state of affairs. But the
> "undefined behavior" sillinesses are one kind of example of where the
> community misleads. Another successful workaround, in industry, has
> been to offload manufacturing to China (which has not agreed to these
> laws). But that introduces language barriers and other problems (which
> are out of scope for this mailing list). Anyways, it seems like
> industry should be demanding laws which enable it to get its work
> done, but this isn't a subject suitable for polite conversation.
>
> I wish I had a good answer here, but I don't...
>
> That said, ... for now at least, focusing on practical issues hasn't
> stopped being essential.
>
> Responses to this message should go to me and not the list.
>
> Thanks,
>
> --
> Raul
>
>
> On Thu, Jan 17, 2019 at 8:07 AM Mayuresh Kathe <[hidden email]> wrote:
> >
> > Don't know if this has been discussed here before, but I found the
> > following excerpt from the article at
> > http://www.yodaiken.com/2018/12/31/undefined-behavior-and-the-purpose-of-c/
> > unnerving;
> > ... often the writers of the ISO C Standard have thrown up their hands
> > and labeled the effects of non-portable and potentially non-portable
> > operations "undefined behavior" for which they provided only a fuzzy
> > guideline.  Unfortunately, the managers of the gcc and clang C compilers
> > have increasingly ignored the guideline and ignored well-established
> > well-understood practice, producing  often bizarre and dangerous results
> > ...
> >
>