Various patches against gmp-4.3.0

[Torbjorn Granlund]

Michiel De Wilde <mdewilde.agilent at googlemail.com> writes:

  >
  >   o dont_redefine_restrict_keyword.diffWindows does not like the
  >
     redefinition of "restrict" as it is being used in some win32 headers
  >
  > This is in an internal gmp file.  Please explain why this can be a
  > problem.
  >

  A #define always changes a name on a global scope level. On Windows, some
  win32 headers that get included use __declspec(restrict), which is now
  changed to __declspec(__restrict), which is invalid. The problem does not
  occur if you include the project name into the identifier that is being
  redefined: "#define GMP_RESTRICT __restrict" instead of "#define restrict
  __restrict" (and replace "restrict" by "GMP_RESTRICT" in the code).

Sorry, I don't see why this reasoning is relevant to the present
situation.  I repeat: gmp-impl.h is an internal GMP file.  Surely its
"global" effects should be quite limited.  :-)

I understand that

#include "gmp.h"
#include "gmp-impl.h"
#include <somesystemheader.h>

can be a problem.  Are you trying to say that we do that in GMP?

If you, as I suspect, are playing with GMP's internal interfaces, you're
onn your own.

Please: specify the exact actualy problem you're trying to solve, don't
just explain us the theory!

  >   o forgotten_extern_C.difffix for t-locale.cc where an extra extern
  >   "C" is needed
  >
  > Why is this needed?

  Without the extern "C", the variable "point_string" is subject to C++ name
  mangling: on win32 it becomes "?point_string@@3PADA", leaving an unresolved
  symbol  "_point_string".

Well, this is a C++ file, point_string is supposed to be a C++ variable,
so if your compiler mangles its use but not its declaration, it sounds
like a serious compiler problem.

    o much_more_declspecs.diffin order to make a GMP dll and run the

  >   testsuite on it, a lot of functions need to be exported in the dll
  >   that currently aren&#39;t
  >
  > I don't see how gmp-impl.h needs this patching.  Please explain!

  We test the gmp dll with the full regression test set. These tests are
  directly accessing functions declared in gmp-impl.h. If these functions are
  not publically exposed in the dll, many tests will fail because they can't
  access the functions.

Ah, so you *are* playing with GMP internals.  Sorry, there are very good
reasons for not trying to make that easier.

  IMO it is worse to disallow the regression suite to run than to expose these
  functions publically in the dll (certainly because, by comparison, on
  Linux/UNIX every function is visible anyway).

Not true.  I have done work on e.g, GNU libc and it surely has internal
functions.

This has nothing whatsoever to do with testing.  The GMP testsuite, and
the test programs in tests/devel test all GMP functions.

  Besides that, the patch also corrects the __GMP_INLINE_PROTOTYPES handling
  for mpn_neg_n.

Yes, and the current snapshot has a fix for that.

  I think there was an error with the "tfprintf" test from mpfr that only
  appears when your system doesn't have a valid vprintf/vsnprintf (such as on
  windows).
  In the function that is being patched, a "goto next" is called to indicated
  the end of a printf formatting item such as the "d" of "%d". A "break"
  appears when detecting modifier characters within a formatting item, such as
  the ".17" in "%.17f". As a "g" or and "f" is the final character of a
  formatting item, there should be a "goto next" and not a "break".

It would be simpler for me to make sure the patch is needed if you sent
me a test case.

Thanks,
Torbjörn