The 64bit future

[CBFalconer]

.... snip ...

Say you're a compiler vendor, depending on customers giving you
money for your product. Your customers have been writing (bad,
non-portable) code for 32-bit systems that assumes long is exactly
32 bits. You want to start selling a version of your compiler for
64-bit systems. If you make long 32 bits, your customers will be
able to recompile their code, and it will still work. If you make
long 64 bits, your customers will have to go back and change their
code (and the modified code will probably be just as non-portable
as the original, just in different ways). Or, more likely, they'll
start buying compilers from your competitor who's still providing
32-bit longs.

If you choose to do the "right thing" and make long 64 bits, I'll
admire your principles, but I doubt that it will turn out well for
your bottom line. My personal inclination would be to provide 64-bit
long; that's probably one of the many reasons I'm not in marketing.

Yes, it's a real problem, and I'd love to see a real solution, but I
don't think it's the vendors' fault.

The problem originated long before C89. The smart thing would have
been to define a system value for INT_MAX, and insist that all
other quasi-int_MAXs be smaller and user set. This was done in
Pascal.

So my advice is to face the standard, as written.

 

[Keith Thompson]

FYI you are at least 10 years too late with that suggestion. C99
has been out since 1999.

The suggestion is compatible with C99. It's perfectly legal for both
long and long long to be 64 bits. (Arguably long wouldn't be *the*
largest integral type, but would be tied for first place.)

 

[Stephen Sprunk]

On the other hand, in the Unix/Linux world compilers *do* seem to be
providing 64-bit long on 64-bit systems, so maybe my entire argument
falls apart, or maybe there's some fundamental difference between
Windows C development and Unix/Linux C development.

The fundamental difference is that most Unix/Linux developers _expect_
their code to be ported to all sorts of bizarre systems or, in the case
of OSS, the code gets ported to bizarre systems by others and the folks
that do the porting work submit patches for unportable constructs. The
result is, either consciously or unconsciously, most OSS is reasonably
portable and programmers get used to seeing such.

OTOH, in the Windows world, most software is written for a single, very
specific target and little, if any, thought is given to making code
portable since the very use of the Windows API means that the code is
inherently not portable to any other system. And that bites them in
their collective ass every time Microsoft makes a major shift -- like
from Win16 to Win32, and now from Win32 to Win64. The 32-bit
assumptions in most code are so deep that even the _Alpha_ port of NT
was ILP32 in user space; the x64 versions at least have 64-bit pointers
and long longs, but long had to be kept 32-bit lest they break virtually
every program out there when recompiled as a 64-bit app. There's even
greater ugliness when you look at hardcoded paths, i.e. SYSTEM32 has
64-bit binaries and SysWow64 has the 32-bit versions...

S

 

[Keith Thompson]

The problem originated long before C89. The smart thing would have
been to define a system value for INT_MAX, and insist that all
other quasi-int_MAXs be smaller and user set. This was done in
Pascal.

It's been done in C as well; see INTMAX_MIN, INTMAX_MAX, and
UINTMAX_MAX.

 

[Phil Carmody]

Where most == windows.

I seem to remember that in Windows on my Dec Alpha a long was 64 bits.
Of course, it didn't spend more than a few days running windows, so my
memory might be inaccurate.

Phil

 

[Stephen Sprunk]

Make long 64 bits on such machines. This actually preserves
compatibility with code that assumes a long can store a pointer, and
that it's the largest integral type.

OTOH, that breaks the massive base of code (written on ILP32 systems)
that assumes sizeof(int)==sizeof(long). That is, reportedly, why
Microsoft went with IL32LLP64 instead of the more common I32LP64.

S

 

[Stephen Sprunk]

I seem to remember that in Windows on my Dec Alpha a long was 64 bits.
Of course, it didn't spend more than a few days running windows, so my
memory might be inaccurate.

Sort of. Windows NT for Alpha was ILP32 in user space; they tried
I32LP64 and IL32P64 (no LL at the time) first, but both broke too much
existing application code.

(IIRC, the kernel used IL32P64 internally; the 64-bit pointers just
weren't exposed to user space.)

S

 

[CBFalconer]

CBFalconer said:

That argument would hold water if it weren't for inline, restrict,
_Bool, _Complex, and _Imaginary, all of which are reserved for use
as keywords and two of which invade user namespace. Clearly,
avoiding adding to the list of reserved words was not a major part
of ISO's thinking.

FYI _Bool, _Complex, and _Imaginary do not add to the list of
reserved words. They are, and have been, reserved for the
implementation.

 

[user923005]

Mark McIntyre said:







I think "inline" and "restrict" demonstrate sufficient blaseitude.



I can and do infer it. Whether I do so correctly is a reasonable
matter for discussion, but only I get to decide what I infer from
whatever information I have. Implication is performed by the writer
or speaker (in this case, ISO). Inference is the preserve of the
reader or listener (in this case, me).

I think that to some degree they were just codifying existing
practice.

The two most popular descriptions for 64 bit integers at the time the
standard containing long long was written were:

long long bigint_value;

and

__int64 bigint_value; /* And a few permutations that looked a lot
like this one ... */

The committee did not invent 'long long' because it was already in
use.

 

[Phil Carmody]

Mark McIntyre said:


I think "inline" and "restrict" demonstrate sufficient blaseitude.

I'd have thought that the majority of prior uses of "inline" would
be for precisely the context they were adopting. So by them opting
to use that keyword, they may well have been doing the majority of
people a favour. "restrict" was a much more curious decision.

Phil

 

[Richard Bos]

copyright alert! I believe that is the chorus and/or backing vocal of at
least one popular song...

Well... it is if you're Chinese. For the rest of us, it's "Da doo ron
ron ron".

Richard

 

[Philipp Klaus Krause]

I guess the main things from a C programmers point of view are
1) 64bit pointers, ability to access regions of memory larger than 4GB (eg
memory mapping large files etc)

Memory mapping large files is something I might want to do on a 64 bit
system.

2) save some typing by using long instead of long long to guarantee
holding integers bigger than 2^32.

Why would I want to use long or long long instead of e.g. int_fast64_t?

Philipp

 

[Keith Thompson]

I think that's a foolish remark and one which strongly suggests you're
trolling for flames, given the prior existence of both keywords and
their prevalence throughout the C world.

[...]

"inline" was adapted from C++, and was provided as an extension by
some pre-C99 compilers. "restrict", however, was an invention of the
C committee; as far as I know, there was no precedent for using that
particular word.

Quoting section 6.4.1 of the C99 Rationale:

Several keywords were added in C89: const, enum, signed, void
and volatile. New in C99 are the keywords inline, restrict,
_Bool, _Complex and _Imaginary.

Where possible, however, new features have been added by
overloading existing keywords, as, for example, long double
instead of extended. It is recognized that each added keyword
will require some existing code that used it as an identifier
to be rewritten. No meaningful programs are known to be quietly
changed by adding the new keywords.

<http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf>

 

[Philipp Klaus Krause]

Because you're programming for two platforms, one of which doesn't
support int_fast64_t?

Well, I'm programming for a platform that doesn't have int_fast64_t, but
it doesn't have long long either. Where are people still using compilers
that have a 64 bit type, but no int_fast64_t?

Philipp

 

[Keith Thompson]

How could it support long long, but not int_fast64_t? Both have the same
guaranteed minimum range.

Perhaps a pre-C99 implementation might support long long as an
extension, but not provide the C99-specific <stdint.h> and/or
<inttypes.h>.

 

[Ian Collins]

Perhaps a pre-C99 implementation might support long long as an
extension, but not provide the C99-specific <stdint.h> and/or
<inttypes.h>.

Such an implementation would still "support" int_fast64_t through a typedef.

 

[Coos Haak]

Op Thu, 30 Apr 2009 18:44:14 +0100 schreef Mark McIntyre:

One of my first interesting C projects was porting a version of gnuplot
from 16-bit big-endian to 8-bit little-endian. The code was littered
with sizeof(int) and endian-specific assumptions when reading and
writing files. Argh.

8-bit little-endian? It must have had 4-bit bytes, a 4040 maybe?

 

[Ian Collins]

But only if the programmer provided it himself.

Well yes, but that doesn't contradict what I said.

 

[Richard Tobin]

How could it support long long, but not int_fast64_t? Both have the same
guaranteed minimum range.

[/QUOTE]

Because long long is mandatory, but the int_*_t types are optional.

7.18.1.1 Exact-width integer types
(3) these types are optional

int_fast64_t is not an exact-width type, and is required.

-- Richard

 

[Ben Bacarisse]

Mark McIntyre said:


I'm reading Chambers: "give the lie to someone or something: to
accuse them of lying".

My Chambers does not have that quote and it does not sound like
dictionary writing so you must be paraphrasing. My Chambers has
two meanings (as does the OED) and you have chosen the second one
rather than the first which is simply to disprove (the OED has
falsify). I don't want to argue over which is the more common usage,
but I am puzzled by why you'd assume the worst. If someone said to me
that "X gives the lie" to something I'd said, I would not want to
assume they were accusing me of lying without more evidence.

Of course, if you never thought it had two meanings, and your
dictionary did not correct this misunderstanding, then there is
nothing to explain and I apologise for any suggestion that your are
being provocative (but you should get a better dictionary).