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