Re: __LONG_MAX__

[Craig Burley <burley at gnu dot org>]

>	* glimits.h (__LONG_MAX__) : Change definition to depend
>	directly on the size of longs. 

More generally, I think the problem with this sort of thing is that
it causes decisions about one system (the system that will run the code
being compiled) to be made based on the environment of another system
(the system that is compiling the code).

One of the (many) challenges of working on a product like gcc (egcs)
is keeping track of the *three* different computer systems that
are involved:

  "Build" system is the one used to build the compiler

  "Host" system is the one that the compiler will run on

  "Target" system is the one for which the compiler will generate code

(Non-code-generating software, which is basically most software,
has only the first two kinds of systems.  But, these are called
"Host" and "Target" in the GNU universe, not "Build" and "Host".)

By avoiding depending on any two of these three systems being the
same, the product becomes that much more amenable to being cross-compiled
and/or configured as a cross-compiler.

I don't know if this applies to the specific case you're addressing --
perhaps glimits.h is used only for compiling build-system components --
but it's a good idea to remember the above in any case.

Certainly, having preprocessor definitions depend on intrinsic compiler
"values" (e.g. "#define FOO (sizeof (int))") makes it effectively
impossible to have those definitions be governed by which system's
header files are #include'd earlier.

So, if glimits.h is used for compiling host- or target-based code,
__LONG_MAX__ should *not* depend on the internal compiler values
of the *build* system.  Instead, the header files #include'd earlier
by the source code should be used, which means using the preprocessor
values they set up (such as `__arch64__').  That way, the Makefiles
can accomplish the cross-compiling by pointing the preprocessor at
the appropriate system's header files, instead of at the build system's.

        tq vm, (burley)

P.S. I'm still learning about the implications of this, so apologizes
in advance if some of the detail above is wrong!