4 ms·
The C23 spec also says: > A potentially reserved identifier becomes a reserved identifier when an implementation begins using it or a future standard reserves
by shakna 1y ago
The C23 spec also says:
> A potentially reserved identifier becomes a reserved identifier when an implementation begins using it or a future
standard reserves it, but is otherwise available for use by the programmer.
Which, in practice, does mean using _t is likely to cause you problems, as it may become a reserved identifier, when an implementation like POSIX begins using it.
- deleted 1y ago[deleted]
- flohofwoe 1y agoStill debatable since the C standard doesn't reserve the _t postfix (it does reserve a single leading underscore followed by a capital letter, e.g. _Bool, and IIRC it also reserves two leading underscores). What POSIX reserves or doesn't reserve doesn't affect code that follows only the C standard but doesn't care about POSIX compatibility, and especially _t is so widely used in C libraries that POSIX's opinion obviously doesn't matter all that much in the real world.
- shakna 1y agoWhilst you do point to 6.4.3 for where it does reserve "All identifiers that begin with a double underscore (__) or begin with an underscore (_) followed by an uppercase letter"... That section also has the lovely: > Other identifiers may be reserved. If an implementation of C uses it... Just... Don't. The standard won't save you here, because it's happy for an implementation to do whatever they feel like.
- flohofwoe 1y agoYeah, and that makes any reserved name rules pretty much useless anyway, e.g. anything goes until a collision actually happens, and then it needs to be fixed on the user side anyway.