Re: Definitions of types also as macros

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sat, Sep 08, 2018 at 11:48:57PM +0000, Christos Zoulas wrote:
 > The problem is that these are defined in multiple headers and
 > typedef redefinition with the same type is a c11 feature, so the
 > define protects against that. Of course one can use a different
 > macro and this was done before, but this has other disadvantages.

How many headers are these (uint32_t etc. in this case) actually
supposed to be defined in? The definitions are in both sys/stdint.h
(which is also stdint.h) and sys/types.h, but sys/types.h includes
sys/stdint.h under some circumstances and there doesn't seem to be any
obvious reason it shouldn't just always do that.

(Failing that, we could make another header to put the common pieces
in, which is most of sys/stdint.h, or make that header sys/stdint.h
and make the userland stdint.h separate, or various other things.)

 > The other approach is:
 > 
 > #ifdef  _BSD_TIME_T_
 > typedef _BSD_TIME_T_    time_t;
 > #undef  _BSD_TIME_T_
 > #endif

I've long felt that the best way to handle this is to give each group
of types that needs to appear in a distinct set of places its own
header file (there aren't actually that many(*)) and rely on the
include guards in the header file to keep from getting multiple copies
of the definitions. It comes out much tidier this way.

This is one of a number of reasons I've long been planning an includes
rototill once we get version control with rename support.


(*) as I recall when I last went through this, when fully sorted out
the only type that actually needed its own header file in this scheme
ended up being size_t, but I'm not sure I'm recalling correctly.

-- 
David A. Holland
dholland%netbsd.org@localhost