5 ms·

Odd choice of title, given that the post is about 'isinf(someInt)' being a compile error (as opposed to treating ints as finite and returning false).

• colomon 13y ago
  Odd title, interesting article. Almost didn't read it, glad I did.
• IanCal 13y ago
  Well I suppose it probably should be. `isinf(someInt)` makes no sense to call and is most likely a logical error. Moreover, it's not defined, so you could have (pseudocode) isinf(x) if (isint(x)) return random() < 0.5 else ... I think the title makes sense, as it's about c ints being finite, and therefore nobody should be calling "isinf" with them. It was interesting that several codebases were.
  • mynegation 13y ago
    While the title is true factually, it does not reflect the main point (using C11 features to improve on unsafe preprocessor constructs). I was almost tempted to say "Yeah... so?" and move on. I am glad I did not, but there are almost certainly others who did.
  • gweinberg 13y ago
    Isn't this really an error in the spec though? Based on what the words mean, isinf and insnan logically should always return false when called with an int argument.
    • lelf 13y ago
      > isinf and insnan logically should always return false when called with an int argument. Yes, but the thing is, they are defined only for floating point types in standard
    • IanCal 13y ago
      Only in the same way that it's an error that the spec doesn't define isinf for strings.