Re: Cygwin off_t, dev_t, uid_t and gid_t definitions

[Sebastian Huber <sebastian dot huber at embedded-brains dot de>]

On 13/04/16 11:07, Corinna Vinschen wrote:
> On Apr 13 10:42, Corinna Vinschen wrote:
> > >On Apr 13 08:18, Sebastian Huber wrote:
> > > > >Hello,
> > > > >
> > > > >we have currently an exception for Cygwin in the <sys/types.h> header:
> > > > >
> > > > >#ifndef __CYGWIN__    /* which defines these types in it's own types.h. */
> > > > >typedef _off_t    off_t;
> > > > >typedef __dev_t dev_t;
> > > > >typedef __uid_t uid_t;
> > > > >typedef __gid_t gid_t;
> > > > >#endif
> > > > >
> > > > >Cygwin defines these types in "winsup/cygwin/include/cygwin/types.h":
> > > > >
> > > > >#ifndef __off_t_defined
> > > > >#define __off_t_defined
> > > > >/* Based on the newlib definitions. */
> > > > >#if __WORDSIZE == 64
> > > > >typedef _off_t off_t;
> > > > >#else
> > > > >typedef _off64_t off_t;
> > > > >#endif
> > > > >#endif /*__off_t_defined*/
> > > > >
> > > > >#ifndef __dev_t_defined
> > > > >#define __dev_t_defined
> > > > >typedef __int16_t __dev16_t;
> > > > >typedef __uint32_t dev_t;
> > > > >#endif /*__dev_t_defined*/
> > > > >
> > > > >#ifndef __uid_t_defined
> > > > >#define __uid_t_defined
> > > > >typedef unsigned short __uid16_t;
> > > > >typedef __uint32_t uid_t;
> > > > >#endif /*__uid_t_defined*/
> > > > >
> > > > >#ifndef __gid_t_defined
> > > > >#define __gid_t_defined
> > > > >typedef unsigned short __gid16_t;
> > > > >typedef __uint32_t gid_t;
> > > > >#endif /*__gid_t_defined*/
> > >
> > >The special types __dev16_t, __uid16_t, and __gid16_t are only used
> > >inside Cygwin to make stone-age old Cygwin applications happy.  These
> > >don't even need the #ifndef __foo_defined bracketing, in fact.  We don't
> > >even need them in a public header.
> > >
> > > > >I think this is misleading since it may conflict with the internal types
> > >
> > >Misleading?!?  In how far?
> > >
> > > > >defined by <sys/_types.h>. Maybe Cygwin should define __dev_t, __uid_t and
> > > > >__gid_t in <machine/_types.h> (where to place this file?).
> > >
> > >winsup/cygwin/include/machine/
> > >
> > > > >Since the default _off_t definition is
> > > > >
> > > > >#ifndef __off_t_defined
> > > > >typedef long _off_t;
> > > > >#endif
> > > > >
> > > > >The off_t definition could be probably simply
> > > > >
> > > > >typedef _off_t off_t;
> > >
> > >No.  off_t is always 64 bit on Cygwin.  _off_t is 32 bit on i686 and 64
> > >bit on x86_64.  That's why off_t is defined as _off64_t on i686 Cygwin.
> > >For that reason we're also using the stdio64 functions in i686 Cygwin
> > >while x86_64 Cygwin uses the normal stdio functions.
> > >
> > >Inside Cygwin the type _off_t is currently used for the same purposes as
> > >the __dev16_t, ... types, to keep really old executables on i686 happy
> > >which have been compiled before Cygwin's off_t has gone 64 bit.
> Ok, one step back.  Right now we have newlib's stdio using _off_t and
> newlib's stdio64 _off64_t.  The assumption is that on 32 bit platforms
> _off_t is a 32 bit type, thus we need _off64_t and stdio64 to implement
> 64 bit file access.

Ok, the _off_t is 64-bit on the main RTEMS targets. I was not aware that 
there is a stdio64. This explains some of my confusion.

> If we change the definitions of _off_t and _off64_t we're bound to break
> newlib and probably not only when being used by Cygwin.
>
> I'd like to suggest the following.  If that's exactly what you suggested,
> bear with me, I'just m trying to wrap my head around this in public:)
>
> - Keep _off_t and _off64_t definitions intact.
>
> - Define __off_t in sys/_types.h as the same type as _off_t, unless
>    we're running on Cygwin.  In that case __off_t should be defined
>    as always 64 bit.

Ok, this makes sense.

> This should probably go into Cygwin's not yet
>    existing machine/_types.h.

No, the <machine/_types.h> is responsible to define _off_t.

> - off_t is always defined as __off_t.  With the above change this should
>    work on Cygwin as well and the definition of off_t in cygwin/types.h
>    can go away.
>
>
> Does that make sense?

Yes, fine. I will try to do this in v3 of the patch.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschÃftliche Mitteilung im Sinne des EHUG.