4 ms·

That's a bit silly. By that logic, every single macro - and every single non-library function call - would be undefined behavior as well. But in general you ar

That's a bit silly. By that logic, every single macro - and every single non-library function call - would be undefined behavior as well. But in general you are right that undefined behavior does not necessarily have to be explicitly stated as such: > If a ‘‘shall’’ or ‘‘shall not’’ requirement that appears outside of a constraint or runtime-constraint is violated, the behavior is undefined. Undefined behavior is otherwise indicated in this International Standard by the words ‘‘undefined behavior’’ or by the omission of any explicit definition of behavior. There is no difference in emphasis among these three; they all describe ‘‘behavior that is undefined’’. I was not aware of this.

kazinator 3y ago
Why yes. This is undefined behavior: int main(void) { char buf[256]; read(0, buf, sizeof buf); } The translation unit doesn't define a read function anywhere, and it's not in ISO C. Suppose that we translate this unit and link it to make a program. There are two possibilities: (1) the program fails to link due to the unresolved reference. (2) it actually links, producing an executable. Under (2) the behavior is undefined. The POSIX read is a documented extension that stands in the place of undefined behavior. Libraries have to allow the ISO C program to define a function called read because the language doesn't reserve the identifier. The GNU C library makes read a weak symbol, aliasing to __libc_read. Internally, it calls __libc_read, so that it doesn't break if the application redefines read. So ISO C undefined behavior is a big area. It contains documented extensions like <unistd.h> and read, well as null pointer dereferences, divisions by zero, out-of-bounds access, double free, ... > I was not aware of this. You might want to keep it to yourself though, if you don't want downvotes.
- spacechild1 3y ago
  > A program that is correct in all other aspects, operating on correct data, containing unspecified behavior shall be a correct program and act in accordance with 5.1.2.3. With your interpretation of undefined behavior, there cannot be any correct program containing #define, #include or (non-library) function calls. This is obviously absurd. The C standard, as any other written text, is ambiguous in certain places and requires interpretation. I am not a language lawyer, but I think your reading of "by the omission of any explicit definition of behavior" is too broad to be useful and it's very likely not what the C standard people intended. It's funny, though! > You might want to keep it to yourself though, if you don't want downvotes. Why? I'm happy to admit when I am wrong or learned something. EDIT unspecified -> undefined
  - kazinator 3y ago
    I'm not aware that I gave an interpretation of unspecified behavior. That is different from undefined behavior.
    - spacechild1 3y ago
      That was obviously a typo. C'mon.
      - kazinator 3y ago
        I don't follow. What is a typo? Whose typo? I see that exact text as far back as C99 (in 4 Conformance) "A program that is correct in all other aspects, operating on correct data, containing unspecified behavior shall be a correct program and act in accordance with 5.1.2.3."
        spacechild1 3y ago
        > I don't follow. What is a typo? Whose typo? My second paragraph did contain a typo ("unspecified" instead of "undefined") which I have fixed (see EDIT). > "A program that is correct in all other aspects, operating on correct data, containing unspecified behavior shall be a correct program and act in accordance with 5.1.2.3." In conjuction with the preceding passage about undefined behavior, I read this as follows: Any program that does not violate ‘‘shall’’ or ‘‘shall not’’ requirements, does not contain undefined behavior and operates on correct data is a correct program; it may, however, contain unspecified behavior. How would you read this instead? Back to 4 ("Conformance"): > [...] Undefined behavior is otherwise indicated in this International Standard by the words ‘‘undefined behavior’’ or by the omission of any explicit definition of behavior. [...] What is an explicit definition? It just isn't possible to completely define any phenomenon down to the smallest detail, so one can always come up with a case that isn't "explicitly defined". IMHO this passage is a mistake in the standard.
        kazinator 3y ago

kazinator 3y ago

Why yes. This is undefined behavior: int main(void) { char buf[256]; read(0, buf, sizeof buf); } The translation unit doesn't define a read function anywhere, and it's not in ISO C. Suppose that we translate this unit and link it to make a program. There are two possibilities: (1) the program fails to link due to the unresolved reference. (2) it actually links, producing an executable. Under (2) the behavior is undefined. The POSIX read is a documented extension that stands in the place of undefined behavior. Libraries have to allow the ISO C program to define a function called read because the language doesn't reserve the identifier. The GNU C library makes read a weak symbol, aliasing to __libc_read. Internally, it calls __libc_read, so that it doesn't break if the application redefines read. So ISO C undefined behavior is a big area. It contains documented extensions like <unistd.h> and read, well as null pointer dereferences, divisions by zero, out-of-bounds access, double free, ... > I was not aware of this. You might want to keep it to yourself though, if you don't want downvotes.

spacechild1 3y ago
> A program that is correct in all other aspects, operating on correct data, containing unspecified behavior shall be a correct program and act in accordance with 5.1.2.3. With your interpretation of undefined behavior, there cannot be any correct program containing #define, #include or (non-library) function calls. This is obviously absurd. The C standard, as any other written text, is ambiguous in certain places and requires interpretation. I am not a language lawyer, but I think your reading of "by the omission of any explicit definition of behavior" is too broad to be useful and it's very likely not what the C standard people intended. It's funny, though! > You might want to keep it to yourself though, if you don't want downvotes. Why? I'm happy to admit when I am wrong or learned something. EDIT unspecified -> undefined
- kazinator 3y ago
  I'm not aware that I gave an interpretation of unspecified behavior. That is different from undefined behavior.
  - spacechild1 3y ago
    That was obviously a typo. C'mon.
    - kazinator 3y ago
      I don't follow. What is a typo? Whose typo? I see that exact text as far back as C99 (in 4 Conformance) "A program that is correct in all other aspects, operating on correct data, containing unspecified behavior shall be a correct program and act in accordance with 5.1.2.3."
      - spacechild1 3y ago
        > I don't follow. What is a typo? Whose typo? My second paragraph did contain a typo ("unspecified" instead of "undefined") which I have fixed (see EDIT). > "A program that is correct in all other aspects, operating on correct data, containing unspecified behavior shall be a correct program and act in accordance with 5.1.2.3." In conjuction with the preceding passage about undefined behavior, I read this as follows: Any program that does not violate ‘‘shall’’ or ‘‘shall not’’ requirements, does not contain undefined behavior and operates on correct data is a correct program; it may, however, contain unspecified behavior. How would you read this instead? Back to 4 ("Conformance"): > [...] Undefined behavior is otherwise indicated in this International Standard by the words ‘‘undefined behavior’’ or by the omission of any explicit definition of behavior. [...] What is an explicit definition? It just isn't possible to completely define any phenomenon down to the smallest detail, so one can always come up with a case that isn't "explicitly defined". IMHO this passage is a mistake in the standard.
        kazinator 3y ago