7.18.1p1 uxxx_t <=> xxx_t
- From: Peter Nilsson <airia@xxxxxxxxxxx>
- Date: Tue, 2 Sep 2008 19:02:13 -0700 (PDT)
My question comes out of a discussion in comp.lang.c in
a thread titled "Typedef Bug/Error".
What is the interpretation of 7.18.1p1, particularly with
regards to exact width types?
n1256 has 7.18.1p1 saying:
When typedef names differing only in the absence or presence
of the initial u are defined, they shall denote corresponding
signed and unsigned types as described in 6.2.5; an
implementation providing one of these corresponding types
shall also provide the other.
It is clear that if both uxxx_t and xxx_t are defined [under 7.18],
they must be corresponding types under 6.2.5.
However, I have been advised that it actually says more:
if _either_ uxxx_t or xxx_t is defined, then so must the other,
and they must be corresponding types under 6.2.5.
In other words, they always exist in pairs as well as
being corresponding types under 6.2.5.
Fundamentally, I'm interpreting 7.18.1p1 as conditional...
When uxxx_t *and* xxx_t are defined...
Defect Report 269 (2002) has a parenthetical comment saying
the intent is that the presence of one requires the presence of
the other...
"...can be derived from the requirement to provide both
or neither of these types..."
But the wording of 7.18.1p1 has radically changed since
then.
Must exact-width types exist in signed/unsigned pairs?
Consider a (freestanding) implementation with the attributes...
CHAR_BIT == 32
UINT_MAX == 4294967295
INT_MAX == 2147483647
INT_MIN == -2147483647 /* sm or 1c, not 2c */
The implementation must define uint32_t. If the exact-width
types must exist in pairs, then it must define int32_t, which it
cannot do if it wishes to claim conformance and align with
the natural architecture.
--
Peter
.
- Follow-Ups:
- Re: 7.18.1p1 uxxx_t <=> xxx_t
- From: lawrence . jones
- Re: 7.18.1p1 uxxx_t <=> xxx_t
- From: Charlie Gordon
- Re: 7.18.1p1 uxxx_t <=> xxx_t
- Prev by Date: Re: C99 portability challenge
- Next by Date: Re: 7.18.1p1 uxxx_t <=> xxx_t
- Previous by thread: Re: C99 portability challenge
- Next by thread: Re: 7.18.1p1 uxxx_t <=> xxx_t
- Index(es):
Relevant Pages
|
