Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I agree that there are cases where a naive implementation would have a hard time distinguishing implementation from program (and even in case of a non-naive implementation, it can be a line drawn in water), so this sort of thing might be warranted. Though that was just one example among many, and there are many instances of undefined behavior that are very much compile-time. For example:

> The same identifier has both internal and external linkage in the same translation unit

> Two declarations of the same object or function specify types that are not compatible

> An attempt is made to use the value of a void expression, or an implicit or explicit conversion (except to void) is applied to a void expression

> An unmatched ' or " character is encountered on a logical source line during tokenization

> Two identifiers differ only in nonsignificant characters

> The identifier __func__ is explicitly declared

> The characters ', \, ", //, or /* occur in the sequence between the < and > delimiters, or the characters ', \, //, or /* occur in the sequence between the " delimiters, in a header name preprocessing token

> An expression that is required to be an integer constant expression does not have an integer type

You get the idea. That's just what I gathered from quickly skimming the first screenful (out of about 4) in the list of UB in N1256.



Yes. These, to me, seem to codify limitations of ancient compilers. Modern compilers will catch these problems at compile time.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: