Thanks for the comments. Good observations.
io_gets.c calls for #include .
Indeed. It's embarrassing to be anal about including all used headers explicitly and then get caught forgetting one in my own code.BTW, why bother with errno at all?
I don't disagree. Idid consider the various options for error handling, and ultimately decided to keep it simple. In this case, simple meant "write it without error handling, then splice in an errno solution".
I firmly (and humbly) believe that a library function may resort to errno only if it can't possibly flag an error in any other way.
I'm not sure I agree with that. There are few (if any) circumstances where errno is the only option. However, for rare errors other options can be too instrusive. For example, an output parameter for out of range conversions in strtol:
result = strtol(s, &end, 0, &out_of_range);
Is that extra parameter really necessary? Maybe, maybe not. But over the years I don't once recall anyone complaining about the design flaw of setting errno to ERANGE. ;)I'd say, it forces the caller not to free it.
I suppose it depends on your perspective. If not having to call free feels like a straight jacket then we can word it in a bad way. If not having to call free feels liberating then we can word it in a good way. What's your take on garbage collection? ;)I don't think it is right.
Right for what? I get the impression that you have unreasonable expectations here. :icon_rolleyes:The library should at least provide a way to reclaim unneeded strings.
I left that part out because I felt it didn't add anything to the example.The way the code handles it (via errno)
Keeping in mind that the codedoes handle that case, whether you agree with the method or not, why add redundancy?
forces the caller to check errno after every call to io_gets. I don't think it is right.
Compared to forcing the caller to check for a newline after every call? Are we to quibble over equivalent implementation alternatives?
Narue
Bad Cop
15,460 posts since Sep 2004
Reputation Points: 6,464
Solved Threads: 1,401
can you explain where these error codes come from?
#define IO_GETS_ALLOC 0x1DE27
#define IO_GETS_NOPOOL 0x1B24A
jephthah
Posting Maven
2,587 posts since Feb 2008
Reputation Points: 2,143
Solved Threads: 179
can you explain where these error codes come from?
#define IO_GETS_ALLOC 0x1DE27
#define IO_GETS_NOPOOL 0x1B24A
My daughter's birthday and my birthday in hexadecimal, respectively. The former is actually a typo. It should be 0x1DE26.
Narue
Bad Cop
15,460 posts since Sep 2004
Reputation Points: 6,464
Solved Threads: 1,401
ah, okay. i'm glad i didnt spend any time searching the standard libraries. :-)
jephthah
Posting Maven
2,587 posts since Feb 2008
Reputation Points: 2,143
Solved Threads: 179
jephthah
Posting Maven
2,587 posts since Feb 2008
Reputation Points: 2,143
Solved Threads: 179
The answer is, absolutely nothing.
That's usually the answer to out of memory conditions. Most of the time all you can do is save state and terminate gracefully. The pointer is still usable, it just contains a potentially partial line. If recovery is possibly by freeing memory elsewhere, nothing stops you from calling io_gets again and pasting the two strings together manually (like you would when fgets reads long lines). I don't see this as an unreasonable situation unless out of memory conditions are common, and in that case you probably shouldn't be using something like io_gets in the first place. ;)
I couldn't agree more that some extra management functionality for the pool is warranted if it's to be truly usable in real code. For basic usage in the example, it's not a big deal. I appreciate you bringing it up though. Hopefully now I won't get bug reports that production code is failing because a pointer couldn't be removed from the pool. :DCorrect me if I am wrong, but the memory will be deallocated at the program exit time anyway.
You're not wrong, but you're not entirely right either. While it's common, this behavior is not guaranteed. Strictly portable code will release memory explicitly.
Narue
Bad Cop
15,460 posts since Sep 2004
Reputation Points: 6,464
Solved Threads: 1,401