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

111–117 of 117 posts

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

#111

Post by camkego »

orthoxerox wrote: post #30

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 argu…

This would be kind of a fun challenge. If you are handling random numbers, well you are limited by disk or memory size. But if the numbers are compressible ala LZ77 or Gzip, then there are ways to use the value’s compression trees to sum the numbers from the least significant digits using the LZ77 style compressed value tree representation. If you go that route, and the numbers are compressible (not random) then the question is whether the compressed input and output trees fit in memory or disk.

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

#112

Post by voidUpdate »

dlcarrier wrote: post #81
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.

Here's a readability tip for working with ASCII numbers: Treat adding and subtracting the ASCIIness as you would multiplying and dividing by a unit in physics. You can add '0' to convert a numeral to ASCII and subtract '0' to convert it back, and you can do direct comparisons between ASCII numerals. if(characters[i] = '0') { ret = ret * 10 + characters[i] - '0'; }

I was trying to remember how to do that, I forgot you can subtract '0', and was thinking that - 0 obviously wouldn't work

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

#113

Post by rbanffy »

thomashabets2 wrote: post #98
rbanffy wrote: post #86

Earlier quoted context omitted.

Passing a negative value to a function that is specifically for converting strings into unsigned numbers is pretty much an error. In the case of functions that return an unsigned number, at least, negative return values can represent errors. It’s more fun when the result can be signed though. Maybe strcmp with the representation of the LONG_MAX, and if it doesn’t match, call strtol and watch for a LONG_MAX indicating…

If that's an error then so is passing in a non number. So catch 22. You can only check for valid numbers if the number is valid?

If you pass a negative number as a string to a function that converts strings representing positive numbers into positive long integers, then yes, it should return an error status instead of the wrong result.

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

#114

Post by Ekaros »

clark_dent wrote: post #45
orthoxerox wrote: post #30

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 argu…

Could you humor a coding noob--how do you deal with utterly insane inputs like that?

At some point you can just refuse. Too many digits. Well time to quit with error.

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

#115

Post by troad »

chowells wrote: post #102
troad wrote: post #99

Earlier quoted context omitted.

Interesting difference in nomenclature. For me, "crash" absolutely includes intentional early termination. A Rust panic, for example. I think that that's by far the dominant usage of crash. It would surprise me if someone used the word crash but intended to exclude panics, etc.

It's a very language-dependent meaning. In C, the only type of crash is the OS shutting it down on some sort of trap. Everything else is the result of an explicit code path. Since we're talking about C, it's the definition I'm using. In other contexts, other definitions will apply.

Definitely! An interesting distinction. I spend much of my time in the BEAM these days, where "let it crash" is a common practice with a very distinct meaning (green threads under supervisor trees, etc). Different strokes.

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

#116

Post by jsmith45 »

prerok wrote: post #74
DowsingSpoon wrote: post #54

Earlier quoted context omitted.

Write once run anywhere? But C already is a "write once run anywhere" language! Though, you usually have to recompile first :) The criticisms related to UB are not about understanding the target platform and the target compiler's behavior. Undefined Behavior is not the same thing as Implementation-defined Behavior, and lots of folks (including me) would be satisfied with reclassifying chunks of UB as the latter. The…

> crash in a C program that turned out to be due to the compiler removing a null check. The what now? Though not lately, I did program in C for 15 years and never seen something like this. I did see some compiler bugs on obscure platforms (SINIX, IRIX, HPUX on Itanium64, etc.) with proprietary compilers, this kind of thing would make really get me shouting. Were you able to determine why the compiler did this? Is it…

If the compiler can find any operation prior to the null check that would be UB if the value is null (even if it is something that in assembly would be harmless, like performing pointer arithmetic on it), the compiler is allowed to assume the pointer is not null, and thus omit the null check. This could then lead to something that will in practice cause problems like dereferencing the pointer.

Compilers keep taking more and more advantage of inferring that a values in variables cannot be `x`, because if it were than some previous usage would have been UB. When people file bugs to complain, the compiler authors point at the spec which allows them to assume that UB behavior never happens, so the compiler behavior is legal. The only counterargument is if the compiler has chosen to document some specific behavior for this UB (possibly only with specific flags enabled) in which case the compiler testing that scenario as proof of impossibility is indeed a bug (when the required flags are set).

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

#117

Post by thomashabets2 »

rbanffy wrote: post #113
thomashabets2 wrote: post #98

Earlier quoted context omitted.

If that's an error then so is passing in a non number. So catch 22. You can only check for valid numbers if the number is valid?

If you pass a negative number as a string to a function that converts strings representing positive numbers into positive long integers, then yes, it should return an error status instead of the wrong result.

Ah, I misunderstood what you meant by "is an error". Agree.
Post reply on HN