No way to parse integers in C (2022)
blog.habets.se
No way to parse integers in C (2022)
1–10 of 117 posts
Re: No way to parse integers in C (2022)
#2I thought it was pretty well known that everything related to strings in C stdlib (including all str... functions) is bad. You just need to bring in your own string library.
Re: No way to parse integers in C (2022)
#3Cant you just:
for(int i = 0; i = 0)
{
ret = ret * 10 + characters[i] - 48;
}
else
{
return ERROR;
}
}
return ret;
Re: No way to parse integers in C (2022)
#4One of the first homework assignments when I learned C back in '83 was after a long lecture on how the string functions are fundamentally broken, and the class introduction to writing C was fixing all of them.
Re: No way to parse integers in C (2022)
#5As a C programmer, I find this kind of bad faith article very irritating.
Yes, the standard library is bad. This is by far the worst part of the C legacy. But it is not that hard to write your own.
String functions like this are not difficult at all, and you can use better naming and semantics, write faster code etc.
C is not the C standard library, ffs.
Re: No way to parse integers in C (2022)
#6Cant you just: for(int i = 0; i = 0) { ret = ret * 10 + characters[i] - 48; } else { return ERROR; } } return ret; Adjust until it actually works, but you get the picture.
You cannot "just" anything in C without hitting a minefield of UB. It is, probably, more economical to convert your entire project to Rust than it is to do the pufferfish spine removal procedure of auditing the code base for UB and replacing the problem areas. With generative AI, the size of project for which this remains true may be as large as "the entire Linux kernel".
Re: No way to parse integers in C (2022)
#7As a C programmer, I find this kind of bad faith article very irritating. Yes, the standard library is bad. This is by far the worst part of the C legacy. But it is not that hard to write your own. String functions like this are not difficult at all, and you can use better naming and semantics, write faster code etc. C is not the C standard library, ffs.
I don't think it's in bad faith.
The distinction between a language and its standard library gets blurry even in theory, and in practice they're nearly inseparable. If a language's standard library has four ways of doing almost the same thing, and they're all fundamentally broken, that's a problem.
Re: No way to parse integers in C (2022)
#8I remember an old project that ran into something like this. I think we just used atoi() or similar and the error check was a string comparison between the original input and a sprintf() of the converted value.
Ugly (and not performant if in a hot path) but it works.
Re: No way to parse integers in C (2022)
#9As a C programmer, I find this kind of bad faith article very irritating. Yes, the standard library is bad. This is by far the worst part of the C legacy. But it is not that hard to write your own. String functions like this are not difficult at all, and you can use better naming and semantics, write faster code etc. C is not the C standard library, ffs.
I don't think it's in bad faith. The distinction between a language and its standard library gets blurry even in theory, and in practice they're nearly inseparable. If a language's standard library has four ways of doing almost the same thing, and they're all fundamentally broken, that's a problem .
[flagged]
Re: No way to parse integers in C (2022)
#10Cant you just: for(int i = 0; i = 0) { ret = ret * 10 + characters[i] - 48; } else { return ERROR; } } return ret; Adjust until it actually works, but you get the picture.
And how does this avoid returning nonsense if the number is too large? (Wrapping if the accumulator is unsigned, straight to UB land if signed.) Not reporting overflows as errors is one of the major problems demonstrated by TFA.