Thou shalt have no other gods before the ANSI C standard 1352

Douglas A. Gwyn

Then read it it again. Because that is what I said.

Yeah, I know, exactly two platforms took advantage of this. Not even the 16-bit x86 C compilers did that (though they supported many different types of pointers, they never pretended their were properly ANSI conformant when using them.)

So a lot of current platforms set NULL to non-zero? I'm just trying to point out that the need is marginal to begin with.

Show me. Of course you and I may have a different definition of "well".

Knowing the width as a compile time constant symbol is not useful in any of the cases I gave above. The number of lines of source code and-or length of the constants for the ideal implementations are monotonic functions of the integer width in all of those cases. It doesn't help to have a precise symbol of the length -- you as the programmer need to know the numeric length when you type in the implementations.

What kind of sense does that make for the problems I gave above?

Oh -- I have no problem with different platforms, but every one I have ever programmed on with a C compiler in the last 10 years (i.e., Solaris, VxWorks, Win32, and Linux) supports 32 bit ints, 2s complement, and IEEE-754 floating point. Oh and I have used wierd stuff like 36-bit processors -- but never tried to program them with *C* compiler. And the next platform I will program in (very likely AMD64) will also support all those things. As DJB points out, the only *real* interesting problem left in portability is dealing with endianness. But usually, you don't even need a different platform to test that since so many file formats and network protocols use different endianness, that you are forced to get things right no matter what platform you are using.

That are not 32 bit, and have no floating point? Why are you so reluctant with your examples? Xscale and PowerPC are the big players in embedded systems. Even cell phones and smart cards having been trying to move to Java -- and that won't happen without 32 bit, 2s complement and IEEE-754 floating point.

Perhaps you are talking about "*New*" ethernet cards that get to use the oldest crustiest simplest processors in the world? Or digital watches or pedometers? But of course they aren't programmed in C now are they ...

Tell that to the Xscale-Arm people. Their processors have always been extremely low power -- but for some reason they seem to like 32-bit and 2s complement. (They were a little slow with the FP, but they got there about 10 years ago.)

Mainstream processor designers I've talked to tell me that register width is not where all the power consumption is. Of course 2s complement has no effect on power, and FP only consumes a lot of power if you implement an agressive-pipelined design.

What you mean none at all?

issues having to do with the variable length arrays.

Of course now your only argument is about who you are going to blame about the reality that is around you. You said 64 bits is around the corner, implying that that has some relevance to the standard -- so explain yourself Mr. "on the C standards committee". I don't like working with standards written by people who are unaware of what it is they are standardizing.

Now would you describe those implementations as "obsolete" or "mainstream"? (I'll give you a hint: My $1000 DIY desktop is faster and has more memory than that $1 million Cray upon which it seemed followed the Fortran standard seemed a helluva lot more important than that C standard.)

A transition to what? Confusion and non-standard convergence? Look Intel tried that with Itanium which was only *slightly* weird by the standards you are talking about (they did the criminal thing of defining long to be 64 bits.) AMD does the more obvious 64 bit extensions and optimize for the LLP64 style ABI, and voila, that standard survives while Itanium turns into a footnote (that has disasterous consequences for HP's high-end roadmap.)

So then why don't they?

I would love to see this *alternative* FP standard and see what kind of reception it gets.

Look if anyone would be willing to implement custom or strange floating point formats (buttuming they lead to any kind of advantage) it would be the graphics vendors. They don't *NEED* to conform with standards since they are insulated by graphics interfaces like Open GL or Direct 3D, where they supply the drivers anyway. But of course, they have moved to IEEE-754 anyways; and it has nothing to do with legacy or compatibility with anything -- its actually just *better* for them to do so.

Yes, I remember these DSPs from 10 years ago. So their compilers have kept up to the date with the latest standards I take it?

Well you better define what you mean be reasonable. Can I still buy such an architecture and get even a C95 compiler for it?

By end users, I meant end-users from the compiler developer's point of view (i.e., people like me.)

You forgot the follow-on remark of "and since I really don't have reason to push for any other thing that got added in C99, and since nobody else around me seems to care and ... uh ... what were we talking about again?" There is no push, or demand from anyone. Its global ennui about it -- "oh yeah that would be nice, wake me up when it comes" is about as much enthusiasm as you'll get.

Well the majority of those same coders are also using a subset of C++. So I'm not sure what kind of a point you are making. I.e., if they are still C coders, then they obviously aren't pushing for C++ -- why do you think they are pushing for C99?

I hope they have been #ifdef'ed it or they supply the file themselves with their own sources, because there are many heavily used C compilers out there that don't have such an include file. Speaking of portability how exactly is someone supposed to pretend to try to use while retaining any hope of being widely portable?

First, that's not what I asked. And second, can you name one?

Oh yeah, "mapping" the shortest and fastest encoding to its ideal corresponding language primitve is some kind of serious choice for the compiler implementor?

-- Paul Hsieh