This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Apr 20 13:12, Sebastian Huber wrote: > > > On 20/04/16 13:07, Corinna Vinschen wrote: > >On Apr 20 11:48, Sebastian Huber wrote: > >>>On 20/04/16 10:49, Corinna Vinschen wrote: > >>>> >Hi Sebastian, > >>>> > > >>>> >On Apr 18 15:29, Sebastian Huber wrote: > >>>>> >>Provide cap_rights_t via <sys/types.h> if __BSD_VISIBLE for BSD > >>>>> >>compatibility. > >>>> >Do we really want to clutter the namespace with all these very > >>>> >FreeBSD-centric types? I'm mostly concerned about this struct > >>>> >cap_rights, but also many of the other types are rather... uncommon. > >>>> >I checked their existence on OpenBSD, NetBSD, and Linux, and none of > >>>> >them define those: > >>>> > > >>>> > addr_t > >>>> > accmode_t > >>>> > cap_rights/cap_rights_t > >>>> > c_caddr_t > >>>> > cpulevel_t > >>>> > cpusetid_t > >>>> > cpuwhich_t > >>>> > uintfptr_t > >>>> > vm_offset_t > >>>> > vm_size_t > >>>> > vm_ooffset_t > >>>> > vm_paddr_t > >>>> > vm_pindex_t > >>>> > > >>>> >addr_t, vm_offset_t, and vm_size_t are defined in Cygwin, but still, > >>>> >do we really want them available generically? __BSD_VISIBLE is set > >>>> >by default... > >>> > >>>For RTEMS we definitely want these types, since we want to use code from > >>>FreeBSD. So, the question is, do all Newlib users want to see these types? > >>>Your survey suggests a no. > >>> > >>>What about the following: > >>> > >>>As the last step of <sys/types.h> add an > >>> > >>>#include <machine/_user_types.h> > >>> > >>>so that a particular Newlib target is able to provide additional user types. > >>> > >>>Move "winsup/cygwin/include/cygwin/types.h" to > >>>"winsup/cygwin/include/machine/_user_types.h". Plague only the RTEMS users > >>>with these FreeBSD types. > >That sounds like a plan but... wouldn't that be ideally the job of > >machine/types.h? Now that the file has no other uses anymore we > >could resurrect it for just this purpose. Given that the idea is > >to define user-visible types, that sounds like the right thing to do > >to me, rather than inventing YA filename. > > > >Yes, no? > > > > Since this file is purely a Newlib speciality and no user should directly > include this header file I think that an underscore file name is better. It > makes searching easier, compared to yet another "types.h". I disagree. There's no _user_types.h anywhere but lots of types.h in various subdirs. I think the machine-specific extention to sys/types.h should called machine/types.h. That's least surprising and easy to find. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat
Attachment:
signature.asc
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |