[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <51814B3F.4040005@eservices.virginia.edu>
Date: Wed, 1 May 2013 13:05:03 -0400
From: "Z. Gilboa" <zg7s@...rvices.virginia.edu>
To: <musl@...ts.openwall.com>
Subject: sign (in)consistency between architectures
Greetings,
The current architecture-specific type definitions
(arch/*/bits/alltypes.h) seem to entail the following inconsistent
signed/unsigned types:
type x86_64 i386
-------------------------------
uid_t unsigned signed
gid_t unsigned signed
dev_t unsigned signed
clock_t signed unsigned
For *uid_t* and *gid_t*, the GNU documentation specifies /_unsigned int_://
//http://www.gnu.org/software/libc/manual/html_node/Reading-Persona.html#index-uid_005ft-3309/
For *dev_t*, the specification requires /_an integer type no narrower
than int//_/: and given the value it is expected to hold (file device
numbers), making it /_unsigned_/ seems to be the correct choice.
/http://www.gnu.org/software/libc/manual/html_node/Attribute-Meanings.html#index-dev_005ft-1500/
*clock_t* is defined as the value returned by clock(), and the manual
page states that "if the processor time used is not available or its
value cannot be represented, the function returns the value (clock_t)
-1." This in turn suggests that clock_t should be a _signed_ type.
/http://www.gnu.org/software/libc/manual/html_node/CPU-Time.html#index-clock_005ft-2607
/As an additional reference, attached is the output generated by
musl-alltypes (posted on April 18) for the above architectures.
/
/Best regards,
Zvi
Content of type "text/html" skipped
View attachment "musl-alltypes.i386" of type "text/plain" (5875 bytes)
View attachment "musl-alltypes.x86_64" of type "text/plain" (5875 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
