Ignoring undefined behaviour
Ignoring undefined behaviour
Posted Oct 28, 2024 19:27 UTC (Mon) by NYKevin (subscriber, #129325)In reply to: Ignoring undefined behaviour by farnz
Parent article: realloc() and the oversize importance of zero-size objects
Posted Oct 29, 2024 9:22 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (3 responses)
I disagree deeply; the people I see arguing that compilers should only care about the ISO standard are a disjoint group from those who say that the standard should expect downstreams to define more behaviour than ISO does. It makes a huge difference, because it's a minority group, who just happen to have positions of power w.r.t. open source C compilers - note that many of the proprietary C compilers don't make the same arguments around "ISO says it's OK" - and your position is a lot like saying that because you hold an opinion, Google as your employer must agree, and that it's unhelpful to view your opinions as separate from Google's.
In practice, if enough of the people who care were to get involved with LLVM and GCC maintenance, and write and enforce documentation for what LLVM and GCC do when ISO says "UB", "IFNDR", "US", and similar terms for "ISO doesn't have a view here", it'd stop being an issue. But that would involve a bunch of people who aren't interested in compilers taking control of compiler projects, and this is an underlying weakness of open source - only people who are genuinely interested in something tend to take control of that thing.
Posted Oct 31, 2024 18:00 UTC (Thu)
by anton (subscriber, #25547)
[Link] (1 responses)
Concerning your suggestion to get involved with LLVM and GCC maintenance, these are big projects with a lot of paid-for participants who have agreed on certain goals and evaluation methods, and these agreements have lead to the current situation. It is unlikely that one or a few volunteers can change the course of these big projects in a way that conflicts with the value system of the paid participants. Even a contribution that did not conflict with that value system was ignored (and the authors of that contribution also presented at a GCC Developer's summit).
Posted Nov 1, 2024 9:22 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
FWIW, LLVM has a (new) community code ownership policy[1] and is actively seeking[2] community members to participate. You're unlikely to change minds if you conflict about something from the paying entities, but it is possible to offer arguments[3] that end up nudging things in the right direction[4] (even if there's a lack of explicit acknowledgement).
[1] https://discourse.llvm.org/t/rfc-proposing-changes-to-the...
Posted Oct 31, 2024 18:02 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link]
1. The GCC/Clang people have publicly stated, in many different fora, for many years, that they will interpret UB as license to do whatever they want. GCC and Clang are also the two most popular compilers in practical use.
That's hardly better.
Ignoring undefined behaviour
Some of us actually work on and publish about compilers (albeit not C compilers), so your slander is just that.
Ignoring undefined behaviour
Ignoring undefined behaviour
[2] https://discourse.llvm.org/t/calling-all-volunteers/82817
[3] https://github.com/bazelbuild/bazel/pull/19940#issuecomme...
[4] https://github.com/bazelbuild/bazel/pull/19940#issuecomme...
Ignoring undefined behaviour
2. The committee ignores (1) and continues to designate things as UB which probably should not be treated in this manner, and then insists that they are not at fault when the compiler writers do exactly what they publicly said they were going to do.