2 ms·
In this particular case the application was already quite POSIX-dependent in other ways, but it's a good point to make -- I did hesitate before deciding on it f
by syntheticnature 10y ago
In this particular case the application was already quite POSIX-dependent in other ways, but it's a good point to make -- I did hesitate before deciding on it for that reason, now that you remind me.
To add additional details, for those who might draw amusement and/or wisdom: In all cases the input/output date/time strings had the same format. Further, a number of the bugs were due to half-implemented reinventions of atoi being involved -- and atoi was definitely available, as one of the reinventions used it! Finally, in at least one case there was a Y2100 problem.
- MaulingMonkey 10y agoTo be fair, I'd reroll atoi too - but only once, with "sufficient" unit tests (e.g. round trip unit tests for INT_MIN..INT_MAX), and only because atoi has no proper error checking nor wchar_t* variants.
- kazinator 10y agoIndeed; atoi in fact invokes undefined behavior in out of range situations; you can only safely use it when the input has been lexically analyzed to be a valid integer of only so many digits as not to overflow. I'd tend to make this re-rolled atoi a wrapper around strtol/wcstol.
- MaulingMonkey 10y ago> atoi in fact invokes undefined behavior in out of range situations Ouch! TIL. You'd think by now I wouldn't be surprised by such things, and yet, somehow I was...