Bug and fix, reopened: "restrict" #define fails on VC

[librik@panix.com]

Torbjorn Granlund <tege at swox.com> wrote:
> What files in GMP are affected?  I suppose it would work just to
> reorder #include order.

The trouble with using #include ordering to fix a problem in config.h
is that config.h macros could be used to determine which header files
to include; there's a potentially fatal interdependency.

Luckily, the only VC header files that use the __declspec(restrict)
syntax in prototypes are <stdlib.h> and <malloc.h>.  (At least that's
true as of Visual C 8.0 / Visual Studio 2005.)  Therefore the affected
files in GMP are those which #include <stdlib.h> after "config.h" (or
gmp-impl.h which includes config.h), and none of them are conditional:

GMP library files:
	invalid.c
	mpf/set_str.c
	printf/asprntffuns.c
	printf/doprnt.c
	printf/doprntf.c
	printf/doprnti.c
	printf/repl-vsnprintf.c
	printf/sprintffuns.c
	printf/vasprintf.c
	scanf/doscan.c

GMP related files:
	tests/misc.c
	tests/spinner.c
	tune/freq.c
	tune/speed.c
	tune/time.c
	tune/tuneup.c

Switching the include order of <stdlib.h> and "config.h" in these
files does fix the build break caused by #define restrict __restrict.

So if you think this is the way to go, I can construct and submit
patches to gmp-bugs.

(ansi2knr.c also matches the pattern, but this file poses a trickier
problem because that file conditionally includes <stdlib.h> based on
macro settings in config.h -- the fatal interdependency.  Fortunately,
ansi2knr.c is not used in the Windows build with either GCC or Visual
C, so I think it can be ignored.)

A practical question:  Once the change is made, what keeps GMP
contributors from mistakenly adding code that includes config.h
and stdlib.h in the more typical order?  I suppose "Reading
ChangeLog entries and cranky posts from me to gmp-bugs" is the
answer to that.



> Unfortunately, Kevin's fix was to stop defining restrict since it
> wasn't actually used in the GMP sources.  Now it is, and it will
> become much more used in future GMP releases.

Yes, I now see that the bug is inherent in autoconf itself.

The AC_RESTRICT macro produces a "#define restrict" line in
config.h that is guaranteed to cause conflicts on any compiler
which has both "__restrict" and "restrict" as distinct keywords.
There's not much that GMP can do to work around this situation.

I wonder if this would be worth bringing up on the autoconf
mailing list.  They are usually good about supporting the native
vendor compilers, although they might make an exception for
Microsoft.  Between this bug and the Cygwin DLL_EXPORT one, I am
a bit uncharitable towards autoconf/automake/libtool this morning.
I don't see any way to fix the bug without breaking existing code
that assumes it can blindly use the "restrict" keyword.


- David Librik
librik at panix.com