issue 7006 - std.math.pow (integral, integral) crashes on negative exponents

[mipri]

On Monday, 16 December 2019 at 02:05:46 UTC, Timon Gehr wrote:
> Anyway, do I really have to argue that arithmetic is useful, or
> that D should compute the correct result for arithmetic
> expressions? The whole line of reasoning where I am somehow
> required to justify my point of view just makes no sense to me.

It really is the case that *someone* needs to do this, because

1. the author of the code didn't share your view;

2. several other people responding to the ticket didn't share
your view; and

3. this condition has persisted for 8 years after the bug was
reported.

But you don't need to justify it that far. Just one level back.
You expect some specific behavior of pow(), but what do you
expect of functions like pow in general? What principle does
pow() violate by having this weirdly implemented domain
restriction? Would you be satisfied if the line were changed to

   enforce(n >= 0, "only natural powers are supported");

or

   assert(n >= 0);

or

   @deprecated("use floating point pow instead")

?

BEGIN Long digression

Suppose D had a filesystem interface without fine error
handling, so that an SomethingHappenedException is all you get
from trying and failing to open a file? The proper importance
level in the ticket system for this would have to be 'shameful'
or 'disqualifying': this would mean that Phobos's file handling
was only suitable for the most trivial of applications, and
that for anything else the first thing you'd have to do is fall
back to C's or some other interface. And the condition itself
would serve as a red flag in general: don't even think about D
for system administration because clearly nobody involved with
it takes those tasks seriously, so even after you work around
this problem you'll certainly run into some other obnoxious
fault that was less obvious.

Real example of that: Lua doesn't come with a regex library.
It's too good for regex, and has some NIH pattern-matcher
that's less powerful and at least as slow as libc regex() in
practice (so, a dozen times slower than PCRE).

This is an obvious problem. Should you work around it and still
try to use Lua for system administration? No! There's a much
more dangerous problem that isn't obvious at all: the normal
'lua' binary that you'd use to run Lua scripts, on startup
it'll silently eval() the contents of a specific environment
variable. This is a 'feature', and also an instant privilege
escalation exploit for any setuid Lua script. "setuid scripts
are bad"? Sure, but languages that system administrators
actually use take some pains to make them less bad, and
sysadmins are not all top-tier. People make mistakes. Quick
fixes are applied. If people started circulating completely
safe only-to-be-run-by-root Lua scripts then one day someone
will set one of them setuid and someone else will notice and
gain root on a box because of it. So it's best just to not use
Lua for this entire class of application from the very
beginning, and the earliest hint that you should do this is
Lua's pattern-matching eccentricity.

END Long digression

I can say all that because I've worked as a sysadmin and have
written and maintained a lot of sysadmin code. I can't say much
at all about std.math. The easy path, "just do what some other
languages do", leads me to libc that doesn't have an integer
pow, or to scripting languages that eagerly return a floating
point result.

Or to https://gmplib.org/manual/Integer-Exponentiation.html