This is the mail archive of the 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]

Re: Cygwin off_t, dev_t, uid_t and gid_t definitions

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?).
> >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  :
PGP     : Public key available on request.

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]