div.c and other questions

[Patrick Pelissier]

> In the div.c code a variable is called 'near'.  MSVC 6 reports that this is
> an old calling convention and is not supported and stops due the error. I'm
> assuming this is a very very old calling convention when near and far
> variable calls were used with stone knives and bearskins.  But MSVC kicks
> about it so I have to deal with it.
> 
> I've changed the variable name to mpfr_near (and others), and div.c compiles
> and functions correctly.  Making the change in the main MPFR code would seem
> to be trivial and would enhance MPFR's cross platform capabilities.

 This is a bug in MSVC! 'near' is declared as a variable of type "mp_limb_t"!
 Are you sure you are using MSVC 6? Aren't there any flags to remove this checking?
 It will be quite strange if you can't remove this checking.
 Could you send exactly the modified file so that we can check for it?

> My other questions are related to building the MPFR tests.  
> 
> The first question has to do with mpfr_print_binary.  The function was moved
> from mpfr.h to mpfr_impl.h.  Is the intent to retain the function only for
> programmers?  The function is required for building most (all?) of the test
> suite, and I'd think it could live back in mpfr.h.  You may be asking
> yourself why would it matter.  The precise issue is that I'm trying to build
> a MSVC 6 DLL for MPFR (I've been working with Brian Gladman's release to
> minimize the number of branches of code).  Moving mpfr_print_binary back to
> mpfr.h allows all of the editing work to provide the code for exporting to
> the DLL in one file.  This keeps the branches more nearly identical (look at
> how divergent GTK had become between the main and win32 branches, ugh!).
> 
> The second question relates to other functions such as mpfr_set_str_binary
> that are needed for the tests but aren't in mpfr.h.  These functions would
> seem to be useful in a 'full DLL release'.  Are there specific reasons why
> functions were segregated into either mpfr.h or mpfr_impl.h?  If the desire
> is to keep them where they are, then the MSVC DLL branch will need to have a
> modified mpfr_impl.h in addition to the modified mpfr.h to export those
> functions into the DLL .
> 
> I'd like to stay as close to the main MPFR development by minimizing both
> the number of edits and the number of files edited that are required to get
> the MSVC DLL functionality.
 
 MPFR is not ready to become a DLL (or a shared library). 
 Couldn't you build just a static library? It is easier, and produces
 faster code.

 mpfr.h is designed to be the User interface, and it is designed to be 
 as small as possible, whereas mpfr-impl defined all the internal
 stuff which may change for each version (and indeed it changes quite often!).

 If you really want to produce a DLL, modifing mpfr-impl.h too is the best
 solution (and shouldn't be too difficult).

 By the way, could you send us (mpfr at loria.fr) the modified files?

> Thanks for all of the work on the library.
 Thanks.

 Sincerely,
  Patrick Pelissier