7 comments

  • Panzerschrek 48 minutes ago
    C number parsing functions are fundamentally broken, since they are locale-dependend. There are many bugs when one parses a number assuming it has decimal point, but later on systems with locale different from one used on developer's machine it may be suddenly comma instead of point. So, one should avoid using them almost always and use std::from_chars (available in new C++ versions) or some other thirdparty library.
    • spacechild1 26 minutes ago
      +1 for `std::from_chars`. It's also by far the fastest of all standard conversion routines.
  • Joker_vD 25 minutes ago
    It's quite astonishing how the historical inability of commonly used programming languages (from FORTRAN all the way to, say, Java/C#) to ergonomically return two values from a function call has caused people to invent all kinds of insane APIs/contracts.

        [double x, errno_t errno] = strtod(s, nullptr);
        if (errno != 0) {
            // ...
        }
    
        [x, _] = strtod(s, nullptr);  // When you're certain the error is impossible or just don't care
    
    Instead, we're stuck with "check if the return value is -1 and if it is, check the global variable errno" at best, and with "the function doesn't really reliably reports its errors so don't feed it malformed data, idc" at worst.
    • fragmede 23 minutes ago
      Thank you for reminding me that, while Python is slow, there are still reasons to pick it over the alternatives.
  • chasil 1 hour ago
    IEEE-754 is a harsh mistress.

    https://en.wikipedia.org/wiki/IEEE_754

  • anitil 1 hour ago
    Even putting aside the ugliness of errno, this is pretty bad. I'm at the point with libc where I try to use as little of it as I can, though I'm not writing a lot of C these days
    • signa11 51 minutes ago
      well, unless you are 'syscalling' someone else is doing it on your behalf.
      • eptcyka 27 minutes ago
        More to libc than syscalls.
        • signa11 15 minutes ago
          ofcourse. forgot the tongue-firmly-in-the-cheek disclaimer.
  • j16sdiz 2 hours ago
    yes. that's why many number crunching app ships / vendors their own math library
  • TZubiri 1 hour ago
    " Dinesh: I said I would do DRM you would do error handling.

    Gilfoyle: Anything to do with errors is more your vibe"

    https://www.youtube.com/watch?v=oyVksFviJVE&t=49

    Oh, this one is easy.

    Just don't make the errors, then you don't have to detect them.

    When your app stops issuing these errors, then you won't have to write blog posts complaining that someone elses code can't handle your errors.

    Definitely you should never be converting strings to floats ever anyways, see how I'm going on a limb here without any knowledge of your application, but then you know that I'm right because there's no reason why you would ever do that?

  • CamperBob2 1 hour ago

         if (sscanf(string,"%lf",&foo) != 1) 
            { 
            bad_float(); 
            }
    
    This has the benefit of handling scientific notation, too, which some of the other CRTL functions inexplicably do not.

    For extra reassurance, initialize foo to NaN or DBL_MAX or something, and verify that it is no longer equal to that value.

    • lelanthran 49 minutes ago
      That doesn't detect overflows and underflows. Also changes based on locale, which is not thread safe (so you cannot set locale, convert, then unset locale).
    • shakna 56 minutes ago
      sscanf has locale things that make it include implementation-defined behaviour, doesn't it?
      • tliltocatl 12 minutes ago
        Anything that isn't C.UTF-8 is totally broken anyway.