why math.h have pow() return double and not int

Question

Out of curiosity I know pow() returns double

Is there any particular reason why math.h has this API with double as argument and return value.

If I have a case where I need an int as the return value I would write my own API as shown below. Why does math.h doesn't have an API something like this and have double pow(double,double);

or Is there one for this? If the answer is too obvious let me know I will delete the question. I couldn't figure out the reason behind this.

int i = pow1(2,4);

int pow1(int i,int j)
{
   int k = 1;
   while(j--)
   {
      k = k*i;
   }
   return k;
}

Answer 1

I would consider the following arguments:

• The C standard library is already quite large, and every extra function has a cost; providing a single pow function which can (at least in principle) treat both floating-points and integers means less functions, which is a good thing;
• The int version is sufficiently simple (modulo overflows and exceptional cases) that someone may code their own if necessary, so it is not felt as an absolute necessity (there are several other similar functions which might also have been provided in the standard library, but probably for similar reasons have not been included);
• How to deal with overflow? IEEE-754 already specifies how to deal with all those nasty exceptional cases for floating-points, but for integers you would have to choose yourself: use errno? Limit the input argument? Provide no guarantees about overflow whatsoever? Should there be a version for each integer type? Or simply one that returns long? If so, then surely people would complain about the lack of an int version, and a short version as well...
• One of the arguably most useful cases of pow for integers is when the base is 2, in which case shifts might be more efficient. Trying to provide an efficient function that detects such cases (otherwise, people would start arguing whether one should use shifts or call ipow, and then more discussion would ensue...), and also when the base is 4, or 8, or 1, or 0, etc., becomes a real issue for the library developer.

In the end, this hypothetical ipow function would either have an extremely verbose and over-specified description (mentioning performance aspects), or it would lack visibility: should a developer reliably expect their ipow function to be optimized for special cases? The user might end up coding their own version to have a better understanding of its behavior, and since this is a relatively simple function, different implementations would abound.

All in all, from the point of view of the user, int pow() seems lacking, but from the point of view of the library developers and maintainers, it is yet another burden that they might not be willing to undertake, for a benefit which is arguably quite limited.

It is even possible that early versions of the library considered including it, then after some discussion realized that it had several shortcomings, and decided to remove it from the API.