Bug 1722 – std.math.nextafter: nextafterl does not exist on Windows

The unittest for D2's std.math does not pass on Windows. It fails to compile because nextafterl used by nextafter(real) is not defined by Windows.

nextafter support for real's doesn't seem to exist in dmc's runtime, so there's no symbol to link against. Andrei added nextafter for float and double in d2 for both linux and windows. I've re-disabled nextafter on real for windows only. Lowering priority to enhancement request. Before D can support nextafter(real) in windows, walter will need to add support for it in his C runtime.

These NotImplemented exceptions should really be compile time errors. People don't generally expect their to-the-metal math libraries to throw exception objects around, they aren't even documented as doing such, and finally it would be a very unpleasant surprise to find out too late that some code compiled into your rocket launcher that tested out fine on linux throws exceptions on critical but seldom-run functions. Ok, you should test, but my point is that the functions know their unconditionally useless on anything but Linux, so they should tell you that as soon as possible, i.e. at compile time.

Are you sure?(In reply to comment #1) > nextafter support for real's doesn't seem to exist in dmc's runtime, so there's > no symbol to link against. Andrei added nextafter for float and double in d2 > for both linux and windows. I've re-disabled nextafter on real for windows > only. Thanks. That was all this bug report was about. The unit tests failing. So you can close it as far as I'm concerned if the tests don't fail after your change. You could just have it call the double version on Windows instead. > Lowering priority to enhancement request. Before D can support nextafter(real) > in windows, walter will need to add support for it in his C runtime.

(In reply to comment #3) > Are you sure?(In reply to comment #1) > You could just have it call the double version on Windows instead. Forget I said that. I completely wasn't thinking about what the function actually does. Better to make it an error to try to nextafter on a real on Windows (compile time error preferably).

I agree strongly with the compilation failure vs runtime error. Problem, changing throw to static assert causes the build of phobos to fail, not user code. :) I can change them to a template, such as: real nextafter()(real x, real y) { version (Windows) static assert(false, "not implemented on windows"); else return std.c.math.nextafterl(x, y); } Templates get to live by more flexible erroring rules. The problem is that it's only source compatible not link compatible with the previous, non-template, version of the function. That's almost certainly acceptable for d2 at this stage of its life.

(In reply to comment #5) > I agree strongly with the compilation failure vs runtime error. Problem, > changing throw to static assert causes the build of phobos to fail, not user > code. :) > > I can change them to a template, such as: > > real nextafter()(real x, real y) > { > version (Windows) > static assert(false, "not implemented on windows"); > else > return std.c.math.nextafterl(x, y); > } > > Templates get to live by more flexible erroring rules. The problem is that > it's only source compatible not link compatible with the previous, > non-template, version of the function. That's almost certainly acceptable for > d2 at this stage of its life. > What about static if'ing the whole thing (and the other functions like it) out for non-Linux? Or make it a template only for non-Linux version(linux) { real nextafter(real x, real y) { return std.c.math.nextafterl(x, y); } } else { real nextafter()(real x, real y) { pragma(msg, "nextafter only implemented on Linux"); } } If not that, then I guess just close it will-not-fix.

The best answer is to get all these functions implemented for windows, potentially in D code rather than relying on the libc/libm implementations. Don donated implementations for tango, so I'll check with him. For the moment, I've checked in a few doc changes so that at least they are accurate and visible.

Fixed DMD 2.012