<div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div> o dont_redefine_restrict_keyword.diffWindows does not like the</div></blockquote>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div>
<div class="im"> redefinition of "restrict" as it is being used in some win32 headers<br><br></div>This is in an internal gmp file. Please explain why this can be a<br>problem.</div></blockquote></div>
<div> </div>
<div>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).</div>
<div> </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"> o forgotten_extern_C.difffix for t-locale.cc where an extra extern<br> "C" is needed<br><br>Why is this needed?</blockquote>
<div><br>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".</div>
<div><br> o much_more_declspecs.diffin order to make a GMP dll and run the<br></div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im"> testsuite on it, a lot of functions need to be exported in the dll<br></div> that currently aren&#39;t<br><br>I don't see how gmp-impl.h needs this patching. Please explain!</blockquote>
<div class="gmail_quote"> </div>
<div class="gmail_quote">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.</div>
<div class="gmail_quote">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).</div>
<div class="gmail_quote"> </div>
<div class="gmail_quote">Besides that, the patch also corrects the __GMP_INLINE_PROTOTYPES handling for mpn_neg_n.</div>
<div class="gmail_quote"> </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"> o relax_multiple_symbols.difffix for t-locale where the same symbol<br> (don&#39;t remember which) appears twice<br>
<br>This patch looks really strange. Is this something needed on Windoze?<br>(Surely, this would break build on any non-Windoze system.)</blockquote>
<div class="gmail_quote"> </div>
<div class="gmail_quote">Sorry, it is indeed only needed on Windows. Otherwise we get an error for a multiply-defined "_localeconv". There may be better solutions than this quick workaround.</div>
<div class="gmail_quote"> </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"></blockquote>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"> o replace_strcasecmp.diffstrcasecmp does not exist on Windows, but</blockquote>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im"> there is an identical alternative: lstrcmpiA<br><br></div>This sort of patching around individual system brokeness is very<br>problematic. I need to thing about this.<br></blockquote>
<div> </div>
<div>The function "strcasecmp" is not standard C, but a POSIX extension.</div>
<div> </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><span id=""></span><br> o repl-vsnprintf.c.difffix for an error in repl-vsnprintf.c<br><br>What error? Do you have a test case?<br>
</blockquote>
<div>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).</div>
<div>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".</div>
<div> </div>
<div>Kind regards,</div>
<div> </div>
<div>Michiel</div>