why unsigned char not work

[Stephen Horne]

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.

I'm not so sure that's as big an advantage as people think. Those
applications that need more than 4GB memory could probably work with
segmented memory quite easily. It's nowhere near as evil as back in
the days when a segment was 64K.

When weighed against all those compatibility issues hidden in old
libraries (pointers casted to/from that UINT32 type-alias, etc)...

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).

Nah - the instruction set still comes in 8-bit chunks, I suspect, so
int should be 8 bits ;-)

The old how-many-bits-is-the-architecture hasn't had a simple answer
for a long time. Data register size doesn't match addressing width,
which doesn't match instruction granularity, which doesn't match bus
width...

 

[Stephen Horne]

* Stephen Horne:

He he.

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

Good luck.

1. I wasn't volunteering.
2. The whole point of the API wrapper I was suggesting was to support
the old API - not a whole stream of new ones.
3. As for documentation, if its compatible with Win32, you only need
to document the extensions.

 

[Paul Brettschneider]

* 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.

FWIW, on other platforms - in the real world - "correct" behaviour is
possible. To me this looks like a bug of the windows platform. long
has been the longest word that fits into a register on every platform I've
seen so far. I cannot imagine why you would break this (unwritten) rule.

#include <iostream>
#define X(T) "sizeof("#T")=" << sizeof(T) << '\n'
int main()
{
std::cout << X(short)
<< X(int)
<< X(long)
<< X(long long)
<< X(size_t);

}

sizeof(short)=2
sizeof(int)=4
sizeof(long)=8
sizeof(long long)=8
sizeof(size_t)=8

 

[Ian Collins]

* 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.

FWIW, on other platforms - in the real world - "correct" behaviour is
possible. To me this looks like a bug of the windows platform. long
has been the longest word that fits into a register on every platform I've
seen so far. I cannot imagine why you would break this (unwritten) rule.

Too much code based on bad assumptions?

 

[Paul Brettschneider]

* 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.

FWIW, on other platforms - in the real world - "correct" behaviour is
possible. To me this looks like a bug of the windows platform. long
has been the longest word that fits into a register on every platform
I've seen so far. I cannot imagine why you would break this (unwritten)
rule.

Too much code based on bad assumptions?

Yes, the reasoning must be something like that.
But since x86-64 is not binary compatible with x86 and you have to recompile
in any case, the sensible thing would have been to provide a 64 bit version
of the platform API where long is really long (i.e. 64 bit). Problematic
code assuming that sizeof(long)=4 is probably only found in some low level
communication code and that is a bug that needs to be fixed anyway.
Then, maybe I'm just too naive for the real world.

 

[Ian Collins]

Yes, the reasoning must be something like that.
But since x86-64 is not binary compatible with x86 and you have to recompile
in any case, the sensible thing would have been to provide a 64 bit version
of the platform API where long is really long (i.e. 64 bit). Problematic
code assuming that sizeof(long)=4 is probably only found in some low level
communication code and that is a bug that needs to be fixed anyway.
Then, maybe I'm just too naive for the real world.

You and the designers of every other popular OS!

 

[Ian Collins]

From http://msdn.microsoft.com/en-us/library/cc953fe1.aspx there are some
interesting points. First, they announce that by the standard
restrictions (independent of Microsoft):

"long long: Larger than an unsigned long."

Where do they get that from? long long isn't even part of the (current)
C++ standard. C99 makes no such statement about the relative size of
unsigned long and long long.

 

[James Kanze]

* 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.

That's the problem. Since the system API is C (with no type
checking), you could, of course, retap all of the system
headers, replacing "long" with "int" in them. But that still
leaves the problem of third party software.

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

Please understand that in this case, the standardization
preceded the "real world" by a couple of decades. Microsoft
made the decision to design their API's in such a way as to make
it impossible to implement a conforming C or C++ compiler on
them. C99 and C++0x contain changes that will make it possible.

 

[James Kanze]

* Stephen Horne:

[...]

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.
;-)

Commercially, the compiler vendors don't really have a choice.
If you can't implement a compliant compiler on the platform, you
can't deliver one, and the market says you must deliver
something.

In the mean time, of course, the lack of compliance means that a
lot of existing, working C programs fail on that platform.

 

[Bo Persson]

* 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.

FWIW, on other platforms - in the real world - "correct" behaviour
is possible. To me this looks like a bug of the windows platform.
long has been the longest word that fits into a register on every
platform I've seen so far. I cannot imagine why you would break
this (unwritten) rule.

Too much code based on bad assumptions?

The assumption was that as long has always been 32 bits on
DOS/Windows, too much of the code depends on that. Perhaps they did
evaluate their own code base?

That the rest of us assume that long is the widest integer type,
seemed to be less important.


Bo Persson