Date: Fri, 26 May 2023 21:22:22 +0200
Hello Hans,
Am Freitag, dem 26.05.2023 um 09:06 -0700 schrieb Hans Boehm via Liaison:
> There are currently also a few more not-obviously-localized forms of undefined behavior, even in the C standard. In N3096, I found
>
> footnote 92 (header names)
this is 6.4.7p3. In general, every UB that is encountered during translation
can affect everything at run-time or even prevent that an executable is created.
So it does not seem to be affected by the interpretation of UB.
In general, it would make sense to clearly classify all UB in run-time or
translation-time, but this is a bit of a different topic.
>
> restrict seems tricky, buit can probably be handled like data races?
Yes, restrict makes certain accesses have UB. If those accesses never
happen, there is no UB. So it can be tied exactly to those accesses.
>
> "The execution of a non-directive preprocessing directive results in undefined behavior."
This is also a translation-time issue. There are more of those. Annex J1 gives a list of all
things which are explicitly UB.
> Referring to signal(): "Use of this function in a multi-threaded program results in undefined behavior."
> Actually, I don't understand why that's there at all. I could see "implementation defined". As it stands,
> if I call signal(), and then create threads, it encounters undefined behavior at the first thread creation?
> Do we guarantee that the standard library doesn't create threads behind the scenes?
No idea, but calling a function seems pretty localized to me?
>
> H.13: "Use of the macro with an argument of a decimal floating type results in undefined behavior."
> This seems likely to be diagnosed way ahead of executing it.
Good point. It should clarified anyway, whether this is translation time or run-time, as this
would have completely different semantics. If it is translation time, it does not seem relevant
here, but if it is run-time, it is localized.
>
> A bunch of the J.2 undefined behaviors, like "A nonempty source file does not end in a new-line character which is not immediately preceded by a backslash character or ends in a partial
> preprocessing token or comment (5.1.1.2)." are purely static code properties.
Yes.
Martin
>
> Hans
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2023/05/1207.php
Am Freitag, dem 26.05.2023 um 09:06 -0700 schrieb Hans Boehm via Liaison:
> There are currently also a few more not-obviously-localized forms of undefined behavior, even in the C standard. In N3096, I found
>
> footnote 92 (header names)
this is 6.4.7p3. In general, every UB that is encountered during translation
can affect everything at run-time or even prevent that an executable is created.
So it does not seem to be affected by the interpretation of UB.
In general, it would make sense to clearly classify all UB in run-time or
translation-time, but this is a bit of a different topic.
>
> restrict seems tricky, buit can probably be handled like data races?
Yes, restrict makes certain accesses have UB. If those accesses never
happen, there is no UB. So it can be tied exactly to those accesses.
>
> "The execution of a non-directive preprocessing directive results in undefined behavior."
This is also a translation-time issue. There are more of those. Annex J1 gives a list of all
things which are explicitly UB.
> Referring to signal(): "Use of this function in a multi-threaded program results in undefined behavior."
> Actually, I don't understand why that's there at all. I could see "implementation defined". As it stands,
> if I call signal(), and then create threads, it encounters undefined behavior at the first thread creation?
> Do we guarantee that the standard library doesn't create threads behind the scenes?
No idea, but calling a function seems pretty localized to me?
>
> H.13: "Use of the macro with an argument of a decimal floating type results in undefined behavior."
> This seems likely to be diagnosed way ahead of executing it.
Good point. It should clarified anyway, whether this is translation time or run-time, as this
would have completely different semantics. If it is translation time, it does not seem relevant
here, but if it is run-time, it is localized.
>
> A bunch of the J.2 undefined behaviors, like "A nonempty source file does not end in a new-line character which is not immediately preceded by a backslash character or ends in a partial
> preprocessing token or comment (5.1.1.2)." are purely static code properties.
Yes.
Martin
>
> Hans
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2023/05/1207.php
Received on 2023-05-26 19:22:26