why unsigned char not work

[Jerry Coffin]

[ ... ]

You're saying a C89 compiler can't have 32-bit 'long' and 64-bit
'size_t'.

Yes, that's correct. I'll even generalize that a bit: in C89, NO
integer type can be larger than long.

That would mean that there are /no/ conforming C89 compilers for 64-bit Windows,
where 'long' is 32 bits and 'size_t' is 64 bits.

Okay, I'll take your word for it.

I don't believe that.

Why not?

You quoted the C99 standard. Either your conclusion, which followed entirely
from a disingenious and fairly creative interpretation of that quote, does apply
to C99, or it doesn't, in which case it doesn't apply to C89 either. Choose.

My interpretation was neither creative nor disingenuous. The latter
borders on a direct accusation, for which I think you owe an apology.

As it happens, my interpretation also matches that the C Committee
used in their response to Defect Report #067. They were asked
essentially the same question being considered here, but in more
detail:

--------------quote-------------------
The terms ``signed integer type,'' ``unsigned integer type,'' and
``integral type'' are defined in subclause 6.1.2.5. The C Standard
also uses the terms ``integer type,'' ``signed integral type,'' and
``unsigned integral type'' without defining them. Integer-valued
bitfields are also introduced in subclause 6.5.2.

[ ... ]

c. Can an implementation extension add other types defined by the C
Standard to any of these six categories?
d. Can an implementation define other types (e.g. __very long) which
belong to any of these six categories?
e. If the answer to (c) or (d), or both, is yes, can size_t and
ptrdiff_t be one of these other types, or must it be a type in the
above list?
[ ... ]

Response

[ ...]
c) No, the list in the C Standard is meant to be exhaustive. For
example, float cannot be defined as an integer type.
d) No strictly conforming program could contain an instance of such a
type. The treatment of such types is beyond the scope of the C
Standard.
e) No, it must be a type in the list. For example, size_t cannot be
defined as unsigned __int24.
--------------end of quote-------------

That _changed_ in C99 though: along with adding the requirement for
long long (in both signed and unsigned variants, of course) C99
defines the listed types as the "standard integer types". It then
adds a completely new possibility: implementation defined "extended
integer types" -- and says the "integer types" are the union of the
standard integer types and the extended integer types (along with
other irrelevant types like _Bool).

 

[Alf P. Steinbach]

* Jerry Coffin:

[ ... ]

You're saying a C89 compiler can't have 32-bit 'long' and 64-bit
'size_t'.

Yes, that's correct. I'll even generalize that a bit: in C89, NO
integer type can be larger than long.

That would mean that there are /no/ conforming C89 compilers for 64-bit Windows,
where 'long' is 32 bits and 'size_t' is 64 bits.

Okay, I'll take your word for it.

I don't believe that.

Why not?

You quoted the C99 standard. Either your conclusion, which followed entirely
from a disingenious and fairly creative interpretation of that quote, does apply
to C99, or it doesn't, in which case it doesn't apply to C89 either. Choose.

My interpretation was neither creative nor disingenuous. The latter
borders on a direct accusation, for which I think you owe an apology.

As it happens, my interpretation also matches that the C Committee
used in their response to Defect Report #067. They were asked
essentially the same question being considered here, but in more
detail:

--------------quote-------------------
The terms ``signed integer type,'' ``unsigned integer type,'' and
``integral type'' are defined in subclause 6.1.2.5. The C Standard
also uses the terms ``integer type,'' ``signed integral type,'' and
``unsigned integral type'' without defining them. Integer-valued
bitfields are also introduced in subclause 6.5.2.

[ ... ]

c. Can an implementation extension add other types defined by the C
Standard to any of these six categories?
d. Can an implementation define other types (e.g. __very long) which
belong to any of these six categories?
e. If the answer to (c) or (d), or both, is yes, can size_t and
ptrdiff_t be one of these other types, or must it be a type in the
above list?
[ ... ]

Response

[ ...]
c) No, the list in the C Standard is meant to be exhaustive. For
example, float cannot be defined as an integer type.
d) No strictly conforming program could contain an instance of such a
type. The treatment of such types is beyond the scope of the C
Standard.
e) No, it must be a type in the list. For example, size_t cannot be
defined as unsigned __int24.
--------------end of quote-------------

That _changed_ in C99 though: along with adding the requirement for
long long (in both signed and unsigned variants, of course) C99
defines the listed types as the "standard integer types". It then
adds a completely new possibility: implementation defined "extended
integer types" -- and says the "integer types" are the union of the
standard integer types and the extended integer types (along with
other irrelevant types like _Bool).

That's interesting, in a sort of political way.

But it means that unless the C89 DR 67 resolution (wrong way, and thus fixed in
C99) was adopted in an intermediate official standard's technical corrigendum,
the C89 standard itself says no such thing.

If there was such a technical corrigendum, then there are no conforming 64-bit
Windows C89 compilers, and hence no conforming 64-bit Windows C++ compilers...

Anyway, regardless of the C comittee's goofup & subsequent correction in C99,
you can't rely on 'size_t' being one of the standard's built-in types (it's a
rather impotent standard that manages to not being implementable on one of the
major platforms, hence my use of the word "goofup", they really did ).

64 bit Windows being the main example that I know, and the reason that I
intentionally left the door open for that. ;-)


Cheers & hth.,

- Alf

 

[Jerry Coffin]

[ ... ]

That's interesting, in a sort of political way.

But it means that unless the C89 DR 67 resolution (wrong way, and thus fixed in
C99) was adopted in an intermediate official standard's technical corrigendum,
the C89 standard itself says no such thing.

Nonsense! Somebody asked some questions, claiming that there was a
defect in the standard. The Committee has three choices in such a
situation: 1) decide it's a defect, and fix it, or 2) decide it's a
defect, but fixing is beyond their current scope (e.g. won't be
considered until the next version of standard), or 3) decide it's not
a defect at all, and simply offer clarification of what the standard
requires.

In this case, they took the third route -- clarified what the
standard said. No change was made or needed, because the standard
already covered the situation. The C89 standard requires exactly what
I said, and the committee has provided a clarification that affirms
that beyond any reasonable misinterpretation or doubt.

 

[Alf P. Steinbach]

* Jerry Coffin:

[ ... ]

That's interesting, in a sort of political way.

But it means that unless the C89 DR 67 resolution (wrong way, and thus fixed in
C99) was adopted in an intermediate official standard's technical corrigendum,
the C89 standard itself says no such thing.

Nonsense! Somebody asked some questions, claiming that there was a
defect in the standard. The Committee has three choices in such a
situation: 1) decide it's a defect, and fix it, or 2) decide it's a
defect, but fixing is beyond their current scope (e.g. won't be
considered until the next version of standard), or 3) decide it's not
a defect at all, and simply offer clarification of what the standard
requires.

In this case, they took the third route -- clarified what the
standard said. No change was made or needed, because the standard
already covered the situation. The C89 standard requires exactly what
I said, and the committee has provided a clarification that affirms
that beyond any reasonable misinterpretation or doubt.

Yeah, that's interesting, in a sort of political way.


Cheers & hth.,

- Alf

 

[Alf P. Steinbach]

* Alf P. Steinbach:

* Jerry Coffin:

[ ... ]

That's interesting, in a sort of political way.

But it means that unless the C89 DR 67 resolution (wrong way, and
thus fixed in C99) was adopted in an intermediate official standard's
technical corrigendum, the C89 standard itself says no such thing.

Nonsense! Somebody asked some questions, claiming that there was a
defect in the standard. The Committee has three choices in such a
situation: 1) decide it's a defect, and fix it, or 2) decide it's a
defect, but fixing is beyond their current scope (e.g. won't be
considered until the next version of standard), or 3) decide it's not
a defect at all, and simply offer clarification of what the standard
requires.

In this case, they took the third route -- clarified what the standard
said. No change was made or needed, because the standard already
covered the situation. The C89 standard requires exactly what I said,
and the committee has provided a clarification that affirms that
beyond any reasonable misinterpretation or doubt.

Yeah, that's interesting, in a sort of political way.

Sorry, I didn't notice your snippage: it means that the C committe has decided
that C89 is not implementable on platforms such as 64-bit Windows.

And thus that it has decided, perhaps before that platform was conceived but it
does not matter, that all 64-bit Windows C89 compilers and C++ compilers, with
'size_t' 64 bit and 'long' 32 bit, are non-conforming, and thus made themselves
utterly irrelevant wrt. this question.

It could be interesting to know exactly /when/ they goofed up in such a major
way (although corrected in C99) -- was it before or after the C++98 standard
was adopted?


Cheers,

- Alf

 

[Bart van Ingen Schenau]

* Alf P. Steinbach:

* Jerry Coffin:

[ ... ]
That's interesting, in a sort of political way.
But it means that unless the C89 DR 67 resolution (wrong way, and
thus fixed in C99) was adopted in an intermediate official standard's
technical corrigendum, the C89 standard itself says no such thing.
Nonsense! Somebody asked some questions, claiming that there was a
defect in the standard. The Committee has three choices in such a
situation: 1) decide it's a defect, and fix it, or 2) decide it's a
defect, but fixing is beyond their current scope (e.g. won't be
considered until the next version of standard), or 3) decide it's not
a defect at all, and simply offer clarification of what the standard
requires.
In this case, they took the third route -- clarified what the standard
said. No change was made or needed, because the standard already
covered the situation. The C89 standard requires exactly what I said,
and the committee has provided a clarification that affirms that
beyond any reasonable misinterpretation or doubt.

Yeah, that's interesting, in a sort of political way.

Sorry, I didn't notice your snippage: it means that the C committe has decided
that C89 is not implementable on platforms such as 64-bit Windows.

No, you have that the wrong way around. Unless 64-bit Windows existed
when the C standard was drafted in 1989, it was Microsoft that decided
not to support the creation of conforming C89 implementations.

And thus that it has decided, perhaps before that platform was conceived but it
does not matter, that all 64-bit Windows C89 compilers and C++ compilers, with
'size_t' 64 bit and 'long' 32 bit, are non-conforming, and thus made themselves
utterly irrelevant wrt. this question.

It could be interesting to know exactly /when/ they goofed up in such a major
way (although corrected in C99)  --  was it before or after the C++98 standard
was adopted?

As far as I can determine, the limitation of having only three integer
types has existed since K&R C, so way before the C++98 standard.
My copy of K&R2 (copyright 1988) states in Appendix A (Reference
Manual): "Besides the char types, up to three sizes of integer,
declared short int, int and long int, are available." [A4.2] There is
no annotation on the paragraph indicating that this has changed from
K&R1.

Cheers,

- Alf

Bart v Ingen Schenau

 

[Alf P. Steinbach]

* Bart van Ingen Schenau:

* Alf P. Steinbach:

* Jerry Coffin:
[ ... ]
That's interesting, in a sort of political way.
But it means that unless the C89 DR 67 resolution (wrong way, and
thus fixed in C99) was adopted in an intermediate official standard's
technical corrigendum, the C89 standard itself says no such thing.
Nonsense! Somebody asked some questions, claiming that there was a
defect in the standard. The Committee has three choices in such a
situation: 1) decide it's a defect, and fix it, or 2) decide it's a
defect, but fixing is beyond their current scope (e.g. won't be
considered until the next version of standard), or 3) decide it's not
a defect at all, and simply offer clarification of what the standard
requires.
In this case, they took the third route -- clarified what the standard
said. No change was made or needed, because the standard already
covered the situation. The C89 standard requires exactly what I said,
and the committee has provided a clarification that affirms that
beyond any reasonable misinterpretation or doubt.
Yeah, that's interesting, in a sort of political way.

Sorry, I didn't notice your snippage: it means that the C committe has decided
that C89 is not implementable on platforms such as 64-bit Windows.

No, you have that the wrong way around. Unless 64-bit Windows existed
when the C standard was drafted in 1989, it was Microsoft that decided
not to support the creation of conforming C89 implementations.

Sorry, but that's completely meaningless. "platforms such as X" does not mean
"X". The committee goof-up that Jerry referred to most probably did not happen
in 1989, it most probably happened much later. And your conclusion about
Microsoft doesn't follow even from your very flawed premises. What you write is
just rubbish. Utterly. Get some coffee. Please.

As far as I can determine, the limitation of having only three integer
types has existed since K&R C, so way before the C++98 standard.

Sorry, but that trivia is some astronomical units beside the point discussed.

My copy of K&R2 (copyright 1988) states in Appendix A (Reference
Manual): "Besides the char types, up to three sizes of integer,
declared short int, int and long int, are available." [A4.2] There is
no annotation on the paragraph indicating that this has changed from
K&R1.

My copy of K&R1 is from 1976, IIRC, but to the degree that what you're writing
has some meaning (I can sort of feel a tendency towards some kind of attempt at
taking an opposing view, sort of free-associating your way in that direction,
but it's very hard to grok) it's completely irrelevant to anything discussed.


Cheers & hth.,

- Alf

 

[Bo Persson]

* Bart van Ingen Schenau:

* Alf P. Steinbach:
* Jerry Coffin:
[ ... ]
That's interesting, in a sort of political way.
But it means that unless the C89 DR 67 resolution (wrong way,
and thus fixed in C99) was adopted in an intermediate official
standard's technical corrigendum, the C89 standard itself says
no such thing.
Nonsense! Somebody asked some questions, claiming that there
was a defect in the standard. The Committee has three choices
in such a situation: 1) decide it's a defect, and fix it, or 2)
decide it's a defect, but fixing is beyond their current scope
(e.g. won't be considered until the next version of standard),
or 3) decide it's not a defect at all, and simply offer
clarification of what the standard requires.
In this case, they took the third route -- clarified what the
standard said. No change was made or needed, because the
standard already covered the situation. The C89 standard
requires exactly what I said, and the committee has provided a
clarification that affirms that beyond any reasonable
misinterpretation or doubt.
Yeah, that's interesting, in a sort of political way.
Sorry, I didn't notice your snippage: it means that the C
committe has decided that C89 is not implementable on platforms
such as 64-bit Windows.

No, you have that the wrong way around. Unless 64-bit Windows
existed when the C standard was drafted in 1989, it was Microsoft
that decided not to support the creation of conforming C89
implementations.

Sorry, but that's completely meaningless. "platforms such as X"
does not mean "X". The committee goof-up that Jerry referred to
most probably did not happen in 1989, it most probably happened
much later. And your conclusion about Microsoft doesn't follow even
from your very flawed premises.

I think it does. The way to get a conforming implementation is of
course to make long wide enough. Keeping both int and long 32 bits on
64 bit Windows was a Microsoft decision.

On the other hand, I don't think they claim strict C89 conformance
anyway, so they are saved by the new C99 wording.


Bo Persson

 

[James Kanze]

* Jerry Coffin:

It's what the C standard says, and has always said.

Note that while the above is true for C++ (until C++0x is
formalized) and C90, it's not true for C99. C99 allows a system
to provide extended integer types as well. The names of such
extended integral types, however, may not impinge on the user's
namespace : something like __int64 or long long long would be
legal, but not size_t.

You're saying a C89 compiler can't have 32-bit 'long' and
64-bit 'size_t'.

That's the situation. C90 and C++03 clearly says that there are
exactly four (no more, no less) unsigned integer types: unsigned
char, unsigned short, unsigned int and unsigned long.

That would mean that there are /no/ conforming C89 compilers
for 64-bit Windows, where 'long' is 32 bits and 'size_t' is 64
bits.

I don't believe that.

Read the standard.

It is an interesting point, however: it does mean that C++ isn't
implementable under 64 bit Windows.

You quoted the C99 standard. Either your conclusion, which
followed entirely from a disingenious and fairly creative
interpretation of that quote, does apply to C99, or it
doesn't, in which case it doesn't apply to C89 either. Choose.

The definition of size_t is identical in C90, C99 and C++03 (and
it won't change in C++0x): size_t must be a typedef (because
there's no other way to define an "integral type" in a header
file) to an unsigned integral type. C90 and C++03 limit
unsigned integral types to exactly four predefined types (in
§3.9.1/3 in C++03); C99 and C++0x allow an implementation to
define additional integral types, but do not allow the names of
these types to impinge on the user address space:

#include <stdio.h>

int main()
{
int size_t = 42 ;
printf( "%d\n", size_t ) ;
return 0 ;
}

is a perfectly legal C program, guaranteed to compile, run and
output 42. It's also a perfectly legal C++ program.

 

[James Kanze]

* Jerry Coffin:

[...]

--------------quote-------------------
The terms ``signed integer type,'' ``unsigned integer type,'' and
``integral type'' are defined in subclause 6.1.2.5. The C Standard
also uses the terms ``integer type,'' ``signed integral type,'' and
``unsigned integral type'' without defining them. Integer-valued
bitfields are also introduced in subclause 6.5.2.
[ ... ]
c. Can an implementation extension add other types defined by the C
Standard to any of these six categories?
d. Can an implementation define other types (e.g. __very long) which
belong to any of these six categories?
e. If the answer to (c) or (d), or both, is yes, can size_t and
ptrdiff_t be one of these other types, or must it be a type in the
above list?
[ ... ]
Response
[ ...]
c) No, the list in the C Standard is meant to be exhaustive. For
example, float cannot be defined as an integer type.
d) No strictly conforming program could contain an instance of such a
type. The treatment of such types is beyond the scope of the C
Standard.
e) No, it must be a type in the list. For example, size_t cannot be
defined as unsigned __int24.
--------------end of quote-------------
That _changed_ in C99 though: along with adding the
requirement for long long (in both signed and unsigned
variants, of course) C99 defines the listed types as the
"standard integer types". It then adds a completely new
possibility: implementation defined "extended integer types"
-- and says the "integer types" are the union of the
standard integer types and the extended integer types (along
with other irrelevant types like _Bool).

That's interesting, in a sort of political way.

It's more than just political. It defines C (and indirectly
C++).

But it means that unless the C89 DR 67 resolution (wrong way,
and thus fixed in C99) was adopted in an intermediate official
standard's technical corrigendum, the C89 standard itself says
no such thing.

The committee's response to the DR was that there was no defect.
This is what the standard currently says. (IMHO, it says so
rather clearly, in fact. I don't see how it could be
interpreted otherwise.)

In C, the guarantee is a very important one (and was broken by
C99): if you wanted to output a size_t, you needed to do:

size_t x ;
printf( "%lu\n", (unsigned long)x ) ;

and you were guaranteed to get the actual value displayed.

There was actually a great deal of argument about this in the C
committee, when the extended types were introduced, because this
guarantee would be broken (and thus, a significant amount of
existing correct code would be broken). In the end, the
committee bit the bullet, and broke the code, but designed the
standard so that it should never be necessary to break code for
this reason again.

If there was such a technical corrigendum, then there are no
conforming 64-bit Windows C89 compilers, and hence no
conforming 64-bit Windows C++ compilers...

Your comment is correct. Windows 64 bits is a platform on which
C++ cannot be implemented. It's also a platform on which many
existing, correct C90 programs will not work correctly.

Anyway, regardless of the C comittee's goofup & subsequent
correction in C99, you can't rely on 'size_t' being one of the
standard's built-in types (it's a rather impotent standard
that manages to not being implementable on one of the major
platforms, hence my use of the word "goofup", they really did
).

The goofup is on the part of Microsoft, not the C standard's
committee. It has long been an established and important
invariant in C that you could represent any unsigned integral
type as an unsigned long, and any signed integral type as a
signed long, without loss of value. Given the lack of type
safety in C (and in C++), you need some sort of guarantee along
these lines in order to write portable code. (There was a
goofup in the C standard committee in introducing long long, and
in allowing extended types wider than long. If more integral
types were needed---which they were---then they should be
required to be situated between char and long in size.)

64 bit Windows being the main example that I know, and the
reason that I intentionally left the door open for that. ;-)

There's no logical requirement that long be a 32 bit type on a
64 bit machine. In fact, there's a logical requirement that it
be a 64 bit type. But of course, with enough market power, one
can ignore logical requirements.

 

[James Kanze]

On Jul 24, 4:57 am, "Alf P. Steinbach" <[email protected]> wrote:

[...]

No, you have that the wrong way around. Unless 64-bit Windows
existed when the C standard was drafted in 1989, it was
Microsoft that decided not to support the creation of
conforming C89 implementations.

It's actually a very serious goofup on the part of Microsoft,
since it breaks a lot of portably written C programs. In C++,
of course, function and operator overloading, templates and such
mean that it's less of a problem, but in C, if you want to
input or output a value, you absolutely have to know its real
(not typedef'ed) type. For things where you don't know the
actual type, like size_t, you have to have a "worst case" type,
or you can't write portable code. In C, the guaranteed "worst
case" type was long, until the vendors started breaking this
guarantee. (Microsoft wasn't the first---most of the Unix
platforms provided a "long long" well before. At least they
weren't stupid enough to typedef any "standard" type to it.)

As far as I can determine, the limitation of having only three
integer types has existed since K&R C, so way before the C++98
standard.

It's four, not three, and it's sizes of integral types, not
integral types. In fact, in C90, there are exactly nine
integral types: char, signed char, unsigned char, short,
unsigned short, int, unsigned int, long and unsigned long.
C++98 adds bool and wchar_t to this list. C99 added _Bool, long
long and unsigned long long, AND the possibility for an
implementation to add extended integral types.

There was a lot of argument about this change in C99; many
members of the committee opposed it because of the amount of
existing code it broke, and because it broke one of the most
basic guarantees C had always given---a guarantee which was
necessary and widely used in portable C.

 

[James Kanze]

But given that C doesn't have overloading, but does (of
course) have implicit conversions, the concept of distinct
integer/character types has always been very fuzzy in C.
Basically, when does the C++ sense of distinctness make any
difference at all in C?

char* p ;
unsigned char* q = p ;

Illegal, and requires a diagnostic, both in C and in C++.

At one time, IIRC, it wasn't that usual for some "hackers" to
have parameter types that were completely different in the
function compared with the prototype. Even structs were
sometimes declared differently in different locations, though
still being treated as the same struct. The linker only cared
about the function name, after all.

Both C and C++ have a lot of undefined behavior. It's true that
because of overloading, declaring a function with different
parameters declares two different functions in C++, rather than
being undefined behavior as in C. And for historical reasons, C
also allows declaring functions without providing any
information with regards to the parameters the function takes;
as long as the function is actually called with the correct
types (no coercion will be done by the compiler, of course), the
program is correct. C also uses a different definition of
structure equivalence, such that:
struct { int a; int b; } ;
is the same type in all translation units (where as in C++, it
is a type not known outside of the scope where the declaration
occurs).

There are also a number of smaller differences: C defines a
notion of compatible type, which C++ doesn't (but C++ has a
couple of very special rules to allow most well written C to
compile anyway). But basically, if you write:
struct S { double a ; } ;
void f( S* p ) ;
in one file, and:
struct S { unsigned short a[ 4 ] ; } ;
void f( S* p ) { /* ... */ }
in another, it's undefined behavior, in both languages.

 

[Jerry Coffin]

[ ... ]

It is an interesting point, however: it does mean that C++ isn't
implementable under 64 bit Windows.

It doesn't mean anything of the sort. The current implementations may
not conform, but that's completely different from it being impossible
to create an implementation that does conform. Just for example, they
could have 8-bit char, 16-bit short, 32-bit int, 64-bit long, and
size_t a typedef for long.

In most implementations int is the same size as either short or long
-- but that is NOT a requirement.

 

[Alf P. Steinbach]

* Jerry Coffin:

[ ... ]

It is an interesting point, however: it does mean that C++ isn't
implementable under 64 bit Windows.

It doesn't mean anything of the sort. The current implementations may
not conform, but that's completely different from it being impossible
to create an implementation that does conform. Just for example, they
could have 8-bit char, 16-bit short, 32-bit int, 64-bit long, and
size_t a typedef for long.

You can't sell such a compiler, since source code using any API won't be correct.

Please understand that with standardization we're talking about supporting the
real world.

"Impossible" does not refer to abstract formalism, it refers to the real world.


Cheers & hth.,

- Alf

 

[Alf P. Steinbach]

* James Kanze:

* Jerry Coffin:

says...

[...]

--------------quote-------------------
The terms ``signed integer type,'' ``unsigned integer type,'' and
``integral type'' are defined in subclause 6.1.2.5. The C Standard
also uses the terms ``integer type,'' ``signed integral type,'' and
``unsigned integral type'' without defining them. Integer-valued
bitfields are also introduced in subclause 6.5.2.
[ ... ]
c. Can an implementation extension add other types defined by the C
Standard to any of these six categories?
d. Can an implementation define other types (e.g. __very long) which
belong to any of these six categories?
e. If the answer to (c) or (d), or both, is yes, can size_t and
ptrdiff_t be one of these other types, or must it be a type in the
above list?
[ ... ]
Response
[ ...]
c) No, the list in the C Standard is meant to be exhaustive. For
example, float cannot be defined as an integer type.
d) No strictly conforming program could contain an instance of such a
type. The treatment of such types is beyond the scope of the C
Standard.
e) No, it must be a type in the list. For example, size_t cannot be
defined as unsigned __int24.
--------------end of quote-------------
That _changed_ in C99 though: along with adding the
requirement for long long (in both signed and unsigned
variants, of course) C99 defines the listed types as the
"standard integer types". It then adds a completely new
possibility: implementation defined "extended integer types"
-- and says the "integer types" are the union of the
standard integer types and the extended integer types (along
with other irrelevant types like _Bool).

That's interesting, in a sort of political way.

It's more than just political. It defines C (and indirectly
C++).

But it means that unless the C89 DR 67 resolution (wrong way,
and thus fixed in C99) was adopted in an intermediate official
standard's technical corrigendum, the C89 standard itself says
no such thing.

The committee's response to the DR was that there was no defect.
This is what the standard currently says. (IMHO, it says so
rather clearly, in fact. I don't see how it could be
interpreted otherwise.)

The exact same wording is interpreted differently in C99, it's rather easy.

And the interpretation is a made-up one, since it out of the blue assigns a very
special and unreasonable meaning (nowhere defined) to a very ordinary term.

In short the C committee screwed up by its resolution of the Defect Report, but
got back on track with C99 (realizing its fundamental screw-up), that's all. ;-)


Cheers,

- Alf

 

[Stephen Horne]

char* p ;
unsigned char* q = p ;

Illegal, and requires a diagnostic, both in C and in C++.

Obviously, I've been focussing so much on overloading that I've been a
bit stupid, and even forgotten where this thread started. Whoops.

 

[Stephen Horne]

I think it does. The way to get a conforming implementation is of
course to make long wide enough. Keeping both int and long 32 bits on
64 bit Windows was a Microsoft decision.

I would have thought they could equally have kept long as 32 bits, but
also have kept size_t as 32 bits. They could still have a 64 bit
integer type, it just wouldn't be an "integer type" in the
standard-defined sense.

Borland C++ 5.02 had 64-bit integer types. They just weren't integer
types in the C89-standard-defined sense - BC++ kept size_t as 32 bit.
Change the back end to one that generates 64-bit executables and the C
support would presumably have been C89 compliant (in this respect),
yet targetting a 64-bit platform.

Basically, you can have a C89-compliant compiler for any 64 bit
platform by keeping all behaviour as it was for a C89-compiler for a
32 bit plaform. You either keep 32 bit limits, or you use work around
them using language extensions. That's how we got 32 bit support in
the days when standard pointer types on DOS compilers were all 16 bit
- remember far pointers? Yuck, yes, but it's possible.

I'm assuming pointers would have to be 32 bits to due to ptrdiff_t,
but I don't think that was defined in C89 anyway - the limits may only
need to apply to integers.

 

[Jerry Coffin]

I would have thought they could equally have kept long as 32 bits, but
also have kept size_t as 32 bits. They could still have a 64 bit
integer type, it just wouldn't be an "integer type" in the
standard-defined sense.

That would work too, but would lose most of the advantages of 64-bit
code, especially direct access to more than 4 GiB of memory. In fact,
they've had exactly that situation with their 32-bit compiler for
years -- an __int64 type in addition to the standard integer types.

You do still run into a few obvious problems with that. For example,
though it's hard to call it a binding requirement, there is language
in the standard saying that int should be the size suggested by the
architecture -- and it's at least open to argument that on 64-bit
Windows, that should be a 64-bit type (and yes, the solution I posted
earlier had exactly the same shortcoming).

 

[Stephen Horne]

You can't sell such a compiler, since source code using any API won't be correct.

You package it with an API-wrapper that presents a C89-compliant
interface such as, for example, one that gives source-level Win32
compatibility plus a few extensions. If someone is really that
desperate for a C89-compliant compiler on 64 bit Windows, thats
probably exactly what they need.

Failing that, there's a surprising amount of command-line apps out
there - some people only need the standard libraries.

 

[Alf P. Steinbach]

* Stephen Horne:

You package it with an API-wrapper that presents a C89-compliant
interface such as, for example, one that gives source-level Win32
compatibility plus a few extensions.

He he.

Have you considered such things as documentation, the constant stream of new
APIs from Microsoft, etc.?

Good luck.

If someone is really that
desperate for a C89-compliant compiler on 64 bit Windows, thats
probably exactly what they need.

It opposite: no one, except some participants in this discussion, is paying the
slightest attention to the C committee's resolution of the DR, and that in
particular means that no compiler vendor is paying attention to the committee's
earlier (before C99) completely at-odds-with-reality stand. ;-)

Failing that, there's a surprising amount of command-line apps out
there - some people only need the standard libraries.

Again, good luck.


Cheers & hth.,

- Alf