Inconsistent guards for internal and user types

Corinna Vinschen vinschen@redhat.com
Wed Apr 13 18:27:00 GMT 2016


On Apr 13 19:18, Sebastian Huber wrote:
> 
> ----- Craig Howland <howland@LGSInnovations.com> schrieb:
> > On 04/13/2016 05:32 AM, Corinna Vinschen wrote:
> > > On Apr 13 10:44, Sebastian Huber wrote:
> > >> Hello,
> > >>
> > >> Newlib defines defaults for internal types via <sys/_types.h> and uses
> > >> <machine/_types.h> to let systems define their own type if necessary. For
> > >> example
> > >>
> > >> #ifndef __dev_t_defined
> > >> typedef short __dev_t;
> > >> #endif
> > >>
> > >> However, the __*_t_defined pattern conflicts with the glibc type guard
> > >> pattern for user types, e.g. dev_t in this this example. I suggest to
> > >> introduce a __machine_*_t_pattern for internal types (defined by
> > >> <machine/_types.h>, used by <sys/_types.h>). For example
> > >>
> > >> #ifndef __machine_dev_t_defined
> > >> typedef short __dev_t;
> > >> #endif
> > > Hmm, ok.  Looks a bit longish but I can't think of anything shorter
> > > and still readable either.
> > >
> > >
> > > Corinna
> > >
> > How about just changing the original order, for example __defined_dev_t (exactly 
> > the same length)?  It would want an explanatory comment somewhere to 
> > differentiate, but that would be needed no matter how it is done, anyway.
> 
> I think this is confusing.  The prefix __machine clearly indicates
> that this has something to do with a machine include.  These defines
> are only used in <sys/_types.h>, so the length shouldn't be a big
> deal.

__machine_foo_t_defined vs. __foo_t_defined is defintely more readable
than __defined_foo_t vs. __foo_t_defined.  The latter certainly needs
an extra look into the documentation, otherwise it looks like a typo.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20160413/75b595a9/attachment.sig>


More information about the Newlib mailing list