5 ms·

How can a (badly chosen) typedef name trigger _undefined behavior_, and not just, say, a compilation error...? I find it difficult to imagine what that would e

by sedeki 4y ago

How can a (badly chosen) typedef name trigger _undefined behavior_, and not just, say, a compilation error...? I find it difficult to imagine what that would even mean.

AstralStorm 4y ago
The problem being that to trigger a compile error the compiler would have to know all its reserved type names ahead of time. It is not required to do so, hence undefined behavior. You might get a wrong underlying type under that name.
- sedeki 4y ago
  But wouldn't one be required to include a particular header in such case (i.e. the correct header for defining a particular type)? I mean, no typedef names are defined in the global scope without including any headers right? Like I find it really weird that a type ending in _t would be UB if there is no such typedef name declared at all. Or is this UB stuff merely a way for the ISO C committee to enforce this without having to define <something more complicated>?
  - hddqsb 4y ago
    [Note: What I originally wrote in my top-level comment was inaccurate; I edited that comment, but later posted another update: https://news.ycombinator.com/item?id=33773043#33775630 https://news.ycombinator.com/item?id=33773043#33775630.] The purpose of this particular naming rule is to allow adding new typedefs such as int128_t. The "undefined behaviour" part is for declaration of any reserved identifier (not specifically for this naming rule). I don't know why the standard uses "undefined behaviour" instead of the other classes (https://en.cppreference.com/w/cpp/language/ub); https://en.cppreference.com/w/cpp/language/ub); I suspect because it gives compilers the most flexibility.
    - hddqsb 4y ago
      [Edit: My link to the behaviour classes was wrong (it was for C++ instead of C), it should have been https://en.cppreference.com/w/c/language/behavior https://en.cppreference.com/w/c/language/behavior]
- halpmeh 4y ago
  Doesn’t the compiler need to know all of the types to do the compilation anyway?
hddqsb 4y ago
I'm not sure, but in general having incompatible definitions for the same name is problematic.
DSMan195276 4y ago
One potential issue would be that the compiler is free to assume any type with the name `foobar_t` is _the_ `foobar_t` from the standard (if one is added), it doesn't matter where that definition comes from. It may then make incorrect assumptions or optimizations based on specific logic about that type which end up breaking your code.
layer8 4y ago
You can declare a type without (fully) defining it, like in typedef struct foo foo_t; and then have code that (for example) works with pointers to it (*foo_t). If you include a standard header containing such a forward declaration, and also declare foo_t yourself, no compilation error might be triggered, but other translation units might use differing definitions of struct foo, leading to unpredictable behavior in the linked program.

by sedeki 4y ago

How can a (badly chosen) typedef name trigger _undefined behavior_, and not just, say, a compilation error...? I find it difficult to imagine what that would even mean.

AstralStorm 4y ago

The problem being that to trigger a compile error the compiler would have to know all its reserved type names ahead of time. It is not required to do so, hence undefined behavior. You might get a wrong underlying type under that name.

sedeki 4y ago
But wouldn't one be required to include a particular header in such case (i.e. the correct header for defining a particular type)? I mean, no typedef names are defined in the global scope without including any headers right? Like I find it really weird that a type ending in _t would be UB if there is no such typedef name declared at all. Or is this UB stuff merely a way for the ISO C committee to enforce this without having to define <something more complicated>?
- hddqsb 4y ago
  [Note: What I originally wrote in my top-level comment was inaccurate; I edited that comment, but later posted another update: https://news.ycombinator.com/item?id=33773043#33775630 https://news.ycombinator.com/item?id=33773043#33775630.] The purpose of this particular naming rule is to allow adding new typedefs such as int128_t. The "undefined behaviour" part is for declaration of any reserved identifier (not specifically for this naming rule). I don't know why the standard uses "undefined behaviour" instead of the other classes (https://en.cppreference.com/w/cpp/language/ub); https://en.cppreference.com/w/cpp/language/ub); I suspect because it gives compilers the most flexibility.
  - hddqsb 4y ago
    [Edit: My link to the behaviour classes was wrong (it was for C++ instead of C), it should have been https://en.cppreference.com/w/c/language/behavior https://en.cppreference.com/w/c/language/behavior]
halpmeh 4y ago
Doesn’t the compiler need to know all of the types to do the compilation anyway?

hddqsb 4y ago

I'm not sure, but in general having incompatible definitions for the same name is problematic.

DSMan195276 4y ago

One potential issue would be that the compiler is free to assume any type with the name `foobar_t` is _the_ `foobar_t` from the standard (if one is added), it doesn't matter where that definition comes from. It may then make incorrect assumptions or optimizations based on specific logic about that type which end up breaking your code.

layer8 4y ago

You can declare a type without (fully) defining it, like in typedef struct foo foo_t; and then have code that (for example) works with pointers to it (*foo_t). If you include a standard header containing such a forward declaration, and also declare foo_t yourself, no compilation error might be triggered, but other translation units might use differing definitions of struct foo, leading to unpredictable behavior in the linked program.