4 ms·
> 'I typedef my structs all the time, and call them something_t, and * something_p’ I wish people would stop perpetuating this particular naming convention. It
by awbrown 10y ago
> 'I typedef my structs all the time, and call them something_t, and * something_p’
I wish people would stop perpetuating this particular naming convention. Its in violation of POSIX which specifically reserves the entire *_t ‘namespace’. Obviously its fine if this is done on a system or environment for which this is irrelevant, but its best avoided otherwise.
- mbel 10y agoThe reality is that if you are creating a library you probably should prefix your types and functions anyway. And rely on the prefix to minimize collision probability. So it doesn't really matter if you put _t and the end of your type aliases. You will probably not get the collisions anyway. Unless POSIX is going to suddenly introduce mylib_array_t or something.
- jbb123 10y agoNo, but your compiler MIGHT decide in a future release that it's a whole lot faster to ignore the header files for standards types and definitions and just copy a pre parsed version of the struct into the symbol table when the header is included. It might look at the _t and decide nope, I don't have a definition for this so it's an error, despite your own definitions. This probably won't happen. But if it does you don't have any grounds for complaint really.
- mbel 10y agoThe compiler to do that would also need to drop C standard compatibility (section 7.1.3 of C99). Which is probably a good reason to complain and to just stop using that version of this purely theoretical compiler.