Re: Possibly ambiguous redefinition of _fpreset()?

On 2/8/2017 5:30 PM, Keith Marshall wrote:
> Guys,
> 
> A recent bug report:
> https://sourceforge.net/p/mingw/bugs/2326/
> 
> prompted me to revisit an idea I've been toying with for a while -- as
> it grows bigger, there may be mileage in offering a dynamic linking
> option for libmingwex.a.  However, when I try to create a DLL, I see:
> 

I toyed with this idea in the distant past but

>   $ mingw32-gcc -shared -o libmingwex-0.dll -Wl,--whole-archive \
>     libmingwex.a -Wl,--no-whole-archive -L.
>   ./libmsvcrt.a(dgrcbs00324.o):(.text+0x0): multiple definition
>    of `_fpreset'
>   ./libmingw32.a(CRT_fp10.o):.../mingwrt/CRT_fp10.c:14: first
>    defined here
>   collect2: error: ld returned 1 exit status
> 

I didn't have the time to resolve this.

> The problem here is Danny Smith's stratagem for overriding the default
> behaviour of MSVCRT.DLL's _fpreset() function, by shoving an alternative
> function of the same name, but with somewhat different behaviour, (which
> he implements in CRT_fp10.c), into libmingw32.a, whence it should be
> statically linked ahead of -lmsvcrt; he then also provided a further
> free-standing implementation, CRT_fp8.c, which attempts to redirect the
> call back to the (*_imp__fpreset)() entry point in MSVCRT.DLL.
> 
> Am I over-thinking this?  Or is this as fragile as it appears?  Was
> Danny off his game, when he wrote this stuff?  I guess it can't be too
> serious a problem, since no issues have been reported in the 15 years
> or so since Danny wrote it, but I can see the following possibilities:
> 
> 1) User creates his own DLL, into which CRT_fp10.o is linked, and its
>    _fpreset() symbol is re-exported; that now provides its own copy of
>    (*_imp__fpreset)(), which neutralizes Danny's stratagem for calling
>    the MSVCRT.DLL implementation.
> 
> 2) User creates his own DLL, within which _fpreset() is called; user
>    then links this DLL to his main program, which he also links with
>    CRT_fp8.o; calls to _fpreset() in his DLL will still be resolved
>    to whichever of CRT_fp10.o or CRT_fp8.o was linked into the DLL
>    itself, ignoring the intent of linking the main program with
>    CRT_fp8.o
> 
> Given that _fpreset() is strictly a Microsoft concept, conforming to no
> known standard, I'd prefer to do away with this ambiguity, and leave it
> to MSVCRT.DLL to resolve all references -- users who value standards,
> and portability, should be using ISO-C99's fesetenv() function anyway.
> Consequently, I've extensively revised Danny's implementation; would
> anyone care to review the attached patch, before I commit it?
> 
> Of course, if the modified fesetenv() function continues to be linked
> statically, from libmingwex.a, the potential for (non-deterministic)
> behavioural ambiguity remains, spanning user created DLLs; that could
> be mitigated by furnishing libmingwex-0.dll as an alternative to a
> statically linked libmingwex.a, so that only a single fesetenv() need
> exist within the process address space.
> 
> One final related issue: Danny's implementations of both CRT_fp10.c
> and CRT_fp8.c defined fpreset(), (without leading underscore), as an
> alias for each of his _fpreset() replacement implementations.  Given
> the complete lack of any defining standard, that seems kind of pointless
> to me.  Right now I've marked this as deprecated, but have retained a
> __LIBIMPL__ stub for it, (reimplemented in terms of fesetenv()), but
> it's messy, and I'd just as soon see it disappear altogether.
> 
> Any thoughts?

Maybe put out a test and call for testers.  Eli at least would probably
give it a try.  Looking at the MSDN recent documentation I would guess
that even MS is going to get rid of it so I would at least test with it
gone.

<quote>
This function is deprecated when compiling with /clr (Common Language
Runtime Compilation) or /clr:pure because the common language runtime
only supports the default floating-point precision.
</quote>

-- 
Earnie

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot