Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No way to parse integers in C (2022)

blog.habets.se

Post reply on HN
Print view View original

21–30 of 117 posts

Re: No way to parse integers in C (2022)

#21

Post by stephc_int13 »

konmok wrote: post #7
stephc_int13 wrote: post #5

As 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 .

If you read the other articles by the same author on his blog, you'll see that he has some strong and weird opinions about C and UB.

Complete BS in my opinion.

Re: No way to parse integers in C (2022)

#22

Post by voidUpdate »

fhdkweig wrote: post #20
voidUpdate wrote: post #3

Cant 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.

What if the number you want to return just happens to be the value of ERROR? You need an error flag that can't be represented as an int, but then C wouldn't let you return it from a function that only returns "int". It is why some languages throw exceptions and why databases have the special "null" value.

I don't use C enough to know what the convention is for throwing an error when the function can return a number anyway. You'd have to ask someone else

Re: No way to parse integers in C (2022)

#23

Post by jerf »

fhdkweig wrote: post #20
voidUpdate wrote: post #3

Cant 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.

What if the number you want to return just happens to be the value of ERROR? You need an error flag that can't be represented as an int, but then C wouldn't let you return it from a function that only returns "int". It is why some languages throw exceptions and why databases have the special "null" value.

And why some very, very special languages have an effectively-global variable called "errno" that you have to check after the call manually, and worry about whether maybe it was populated from some previous error. Nothing says "production-quality language that an entire civilization's code base should be based on" like "sometimes (but only sometimes!) functions return additional information through global values".

Re: No way to parse integers in C (2022)

#24

Post by aleph_minus_one »

jerf wrote: post #23
fhdkweig wrote: post #20

Earlier quoted context omitted.

What if the number you want to return just happens to be the value of ERROR? You need an error flag that can't be represented as an int, but then C wouldn't let you return it from a function that only returns "int". It is why some languages throw exceptions and why databases have the special "null" value.

And why some very, very special languages have an effectively-global variable called "errno" that you have to check after the call manually, and worry about whether maybe it was populated from some previous error. Nothing says "production-quality language that an entire civilization's code base should be based on" like "sometimes (but only sometimes!) functions return additional information through global values".

> And why some very, very special languages have an effectively-global variable called "errno" that you have to check after the call manually, and worry about whether maybe it was populated from some previous error.

As you can read at https://en.wikipedia.org/wiki/Errno.h errno is barely used by the C standard (though defined there). It is rather POSIX that uses errno very encompassingly. For example the WinAPI functions use a much more sensible way to report errors (and don't make use of errno).

Re: No way to parse integers in C (2022)

#25

Post by alexfoo »

1718627440 wrote: post #17
alexfoo wrote: post #11

Earlier quoted context omitted.

Exactly. A wrapper that handles all of the edge cases properly and gives proper reporting just gets added to your own library of functions and the devs get used to using it. Much like the code for abstract data types like lists/hashmaps/etc which neither C nor the standard libraries provide. Bonus points for having bespoke linting rules to point out the use of known “bad” functions. In one old project we went through…

> like lists/hashmaps/etc which neither C nor the standard libraries provide There is a hashmap implementation though: https://man7.org/linux/man-pages/man3/hsearch.3.html

Sure there's an implementation, but like the integer comparison functions that sparked this thread there are some severe limitations with the implementation.

(In fact, looking at it again, I assume I'd purposely purged it from my memory given how terrible it is.)

The non-extensible nature is the biggest one. There are plenty of times when the maximum number of elements needed to be stored will be known in advance. (See the note about hcreate().)

Secondly the hserach() implementation requires the keys to be NUL terminated strings since "the same key" is determined using strcmp(). Good luck if you want to use a number, pointer, arbitrary structure or anything else as a key.

Any reasonable hash table implementation would not have either of these limitations.

Maybe I needed to say:

> > like lists/hashmaps/etc which neither C nor the standard libraries provide

... reasonable implementations of.

Re: No way to parse integers in C (2022)

#26

Post by Thiez »

voidUpdate wrote: post #14
Sharlin wrote: post #10

Earlier quoted context omitted.

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.

you could check if ret > ret * 10 + characters[i]-48, if so it has wrapped around and you return an error

[dead]

Re: No way to parse integers in C (2022)

#27

Post by psvv »

bsenftner wrote: post #4

One 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.

My memory growing up is that making your own C library was basically an inevitable rite of passage for any aspiring programmer.

Re: No way to parse integers in C (2022)

#30

Post by orthoxerox »

I wasn't in this class myself, but one prof at my alma mater started his "Programming 201" class with the simplest assignment: write a C program that accepts two integers from the user and prints their sum. It actually was the only assignment for the rest of the semester, since he has a test suite that would humiliate the students gently at first, but would ultimately pipe a billion nines into stdin as the first argument.
Post reply on HN