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

You didn't say that, but anyway, C provides a generic data pointer type that you should use for that.

There is an excellent reason that pointer to byte is allowed to be wider than pointer to word.

Actually there are a lot of current platforms that would qualify.

You don't sound like you're at all concerned with portability. Such operations aren't hard to do portably and well. specify precise integer widths, or simply don't use more bits in a type than the standard guarantees are *in* representations of values for that type.

The question is, can you be sure that your code will never be used on a different platform? If so, how?

You clearly don't know anything about embedded systems. *New* processor designs have recently targeted that area more than the desktop area. Also, for many embedded applications, power consumption is a crucial factor, so applying hardware "overkill" in the form of excessively wide registers, data paths, and ALUs is not acceptable.

In fact there are a lot of current embedded systems for which highly conforming C implementations have been available for a long time now. There has been about the same rate of transition to C99 among such systems sticking point, because it requires more than minimal changes to existing C89 compilers.

With programmers like you having built that buttumption into their code, the vendors evidently decided that it would enhance marketability if such fools weren't going around saying how their programs had been "broken" by a contrary implementation.

I've used implementations of C on systems that would fairly be described as "64 bit" where int was 64 bits wide. At some future date, the 32-bit desktop world could find itself making such a transition. It isn't very hard for most compilers to provide the option of doing it either way.

Nope. IEEE is currently standardizing decimal f.p., and there are strong arguments in favor of doing so.

Yes, indeed. For example, T.I. DSPs have a *very* good C compiler and optimizing buttembler that can automate scheduling of the disparate processing elements to a degree comparable with the best that one can do manually, with much less work and less chance of error.

Not really. In fact that vendor didn't press all that hard. The fact is, C is meant for *portable* use in *systems implementation*, which means that it needs to efficiently accommodate a wide variety of reasonable architectures.

Just because *you* don't see much variety does not mean that the variety isn't out there.

That's not true. There are implementations that are advertised as fulling conforming to the 1999 standard. End users are not customers for compilers. If you mean programmers, I have seen many remarks along the lines of "I would use a VLA for this, except I can't yet count on it being supported on all platforms to which I want to port my software". Since C99 is almost entirely upward compatible with C89, very likely the *majority* of C coders can be considered to already be using (a subset of) C99. Certainly many of them have adopted features such as new headers and library functions that can be "added on"

Actually there is a lot of new *hardware* that doesn't have 32 bits as its natural ("native") integer width. The decision of whether to map "int" to the native width or to something that caters to programmers like you, is up to the compiler implementor (or these days more usually the ABI specifier).