headers
Steven Drake | 1 Jul 2012 03:22
Picon

u_intX_t vs. uintX_t

This is to let everyone know about this issue I've just come across, to 
do with the u_intX_t and uintX_t type groups (where X is 8, 16, 32, or 64).

Different OS's define the two groups (strangely) in different places:

+ Linux and NetBSD have (since before C99) made available the u_intX_t
  group from <sys/types.h>

After C99:

+ NetBSD has made uintX_t group available from both <sys/types.h> and 
  <stdint.h>.

+ Linux has made the uintX_t group available from <stdint.h> (but _not_
  <sys/types.h>).

+ SunOS have made the uintX_t group available from <sys/types.h> 
  and <stdint.h>. (well I'm assuming it does.)

If you can't see the problem, may developers include <sys/types.h> and use
the u_intX_t group, which doesn't means a package won't build on SunOS,
simply changing them to uintX_t types means it now build on SunOS but 
not on Linux anymore!

--

-- 
Steven
Permalink | Reply |
headers
Greg Troxel | 1 Jul 2012 03:25
Picon

Re: u_intX_t vs. uintX_t


Steven Drake <sbd <at> NetBSD.org> writes:

> This is to let everyone know about this issue I've just come across, to 
> do with the u_intX_t and uintX_t type groups (where X is 8, 16, 32, or 64).
>
> Different OS's define the two groups (strangely) in different places:
>
> + Linux and NetBSD have (since before C99) made available the u_intX_t
>   group from <sys/types.h>
>
> After C99:
>   
> + NetBSD has made uintX_t group available from both <sys/types.h> and 
>   <stdint.h>.
>
> + Linux has made the uintX_t group available from <stdint.h> (but _not_
>   <sys/types.h>).
>
> + SunOS have made the uintX_t group available from <sys/types.h> 
>   and <stdint.h>. (well I'm assuming it does.)
>
> If you can't see the problem, may developers include <sys/types.h> and use
> the u_intX_t group, which doesn't means a package won't build on SunOS,
> simply changing them to uintX_t types means it now build on SunOS but 
> not on Linux anymore!

So a program is broken unless:

  it uses uintX_t, and
(Continue reading)

Permalink | Reply |
headers
Steven Drake | 1 Jul 2012 05:20
Picon

Re: u_intX_t vs. uintX_t

On Sat, 30 Jun 2012, Greg Troxel wrote:

> So a program is broken unless:
> 
>   it uses uintX_t, and
>   include stdint.h
>
> Is that what you mean?   This seems  to be in the category of "common
> upstream bug"

No, if it's using u_intX_t and including sys/types.h thats ok (I can't
find any reference to them being part of any standard but they are common.
i.e. Linux/NetBSD/FreeBSD).

If a pkgsrc developer decides to change u_intX_t to uintX_t so that the
program build on a OS that doesn't have them the they must make sure that
stdint.h is included to C99 compliant.

> - are you proposing to have some accomodation in pkgsrc?

No, just for pkgsrc developers to be careful.

> I'm guessing that this bug is common in linuxy programs...

No because u_intX_t has  been available on both Linux, NetBSD and FreeBSD
(possibly others) since the late 90's.

--

-- 
Steven
(Continue reading)

Permalink | Reply |
headers
Hans Rosenfeld | 1 Jul 2012 12:22
Picon

Re: u_intX_t vs. uintX_t

On Sun, Jul 01, 2012 at 03:20:47PM +1200, Steven Drake wrote:
> > I'm guessing that this bug is common in linuxy programs...
>  
> No because u_intX_t has  been available on both Linux, NetBSD and FreeBSD
> (possibly others) since the late 90's.

That doesn't really help anyone on systems which don't have them (SunOS,
and possibly others). So getting rid of that non-standard crap is IMHO
the way to go.

uintXX_t and stdint.h vs. sys/types.h (and what about inttypes.h?) is
then just an issue of _how_ to fix it properly.

Hans

--

-- 
%SYSTEM-F-ANARCHISM, The operating system has been overthrown
Permalink | Reply |
headers
Steven Drake | 2 Jul 2012 02:48
Picon

Re: u_intX_t vs. uintX_t

On Sun, 1 Jul 2012, Hans Rosenfeld wrote:

> On Sun, Jul 01, 2012 at 03:20:47PM +1200, Steven Drake wrote:
> > > I'm guessing that this bug is common in linuxy programs...
> >  
> > No because u_intX_t has  been available on both Linux, NetBSD and FreeBSD
> > (possibly others) since the late 90's.
> 
> That doesn't really help anyone on systems which don't have them (SunOS,
> and possibly others). So getting rid of that non-standard crap is IMHO
> the way to go.

Agreed.

> uintXX_t and stdint.h vs. sys/types.h (and what about inttypes.h?) is
> then just an issue of _how_ to fix it properly.

Thats my point exactly, how to fix it _properly_.

In the last few days I fixed a couple of packages because they had been 
patched to "Fix build on SunOS." by using the uintX_t types but they had 
not been patch to include stdint.h at the same time which mean they 
no longer built on Linux.

--

-- 
Steven
Permalink | Reply |
headers
Georg Schwarz | 2 Jul 2012 20:23
Picon
Favicon

Re: u_intX_t vs. uintX_t


Am 02.07.2012 um 02:48 schrieb Steven Drake:

> Thats my point exactly, how to fix it _properly_.

would an appropriate CPPFLAGS.SunOS+=-D... help?

--

-- 
Georg Schwarz  http://home.pages.de/~schwarz/
georg.schwarz <at> freenet.de +49 170 8768585
Permalink | Reply |
headers
David Holland | 1 Jul 2012 04:28
Picon

Re: u_intX_t vs. uintX_t

On Sun, Jul 01, 2012 at 01:22:06PM +1200, Steven Drake wrote:
 > This is to let everyone know about this issue I've just come across, to 
 > do with the u_intX_t and uintX_t type groups (where X is 8, 16, 32, or 64).
 > 
 > Different OS's define the two groups (strangely) in different places:
 > 
 > + Linux and NetBSD have (since before C99) made available the u_intX_t
 >   group from <sys/types.h>
 > 
 > After C99:
 >   
 > + NetBSD has made uintX_t group available from both <sys/types.h> and 
 >   <stdint.h>.
 > 
 > + Linux has made the uintX_t group available from <stdint.h> (but _not_
 >   <sys/types.h>).
 > 
 > + SunOS have made the uintX_t group available from <sys/types.h> 
 >   and <stdint.h>. (well I'm assuming it does.)
 > 
 > If you can't see the problem, may developers include <sys/types.h> and use
 > the u_intX_t group, which doesn't means a package won't build on SunOS,
 > simply changing them to uintX_t types means it now build on SunOS but 
 > not on Linux anymore!

If it uses uint*_t, it should include <stdint.h>. C99 says so.

Therefore (as I was hinting in pkgsrc-changes) if you add stdint.h
because of uint*_t, don't hide it in platform-dependent ifdefs. This
will just cause someone else to have to come fix it again at some
(Continue reading)

Permalink | Reply |
headers
Steven Drake | 1 Jul 2012 05:22
Picon

Re: u_intX_t vs. uintX_t

On Sun, 1 Jul 2012, David Holland wrote:

> If it uses uint*_t, it should include <stdint.h>. C99 says so.

Exactly what I meant.

> Therefore (as I was hinting in pkgsrc-changes) if you add stdint.h
> because of uint*_t, don't hide it in platform-dependent ifdefs. This
> will just cause someone else to have to come fix it again at some
> future point.

I agree and will change it.

--

-- 
Steven
Permalink | Reply |
headers
David Holland | 1 Jul 2012 21:40
Picon

Re: u_intX_t vs. uintX_t

On Sun, Jul 01, 2012 at 03:22:46PM +1200, Steven Drake wrote:
 > > If it uses uint*_t, it should include <stdint.h>. C99 says so.
 > 
 > Exactly what I meant.
 > 
 > > Therefore (as I was hinting in pkgsrc-changes) if you add stdint.h
 > > because of uint*_t, don't hide it in platform-dependent ifdefs. This
 > > will just cause someone else to have to come fix it again at some
 > > future point.
 > 
 > I agree and will change it.

I think we're all on the same page then :-)

--

-- 
David A. Holland
dholland <at> netbsd.org
Permalink | Reply |

Gmane