Wasting hours in an offhand way

[pjp]

I've been working on a program to process command line arguments.

A function converts an argv string to a number, and returns that number. Mixing valid return values with some "magic" value indicating error didn't seem like a good approach. So I used a custom true / false error type to indicate failure in converting the string to a value.

Handling a section of optional arguments with optional values appeared to have a logic error I couldn't find. I rewrote that section a couple of different ways, creating different errors in the process.

I finally thought I had a cleaner approach to the logic and adapted that example to the program. And, it still didn't produce correct results. It was failing to convert a number when it should have been able to. I finally discovered that the number was being converted correctly. It wasn't being used because I didn't reset the error condition to false for use with the next argument.

Yeah. I spent too many hours on that across multiple days.

I'll eventually try doing it with pointer math again. At least the errors incrementing the pointer too much were obvious :)
_________________
Quis separabit? Quo animo?

[gorg86]

Stuff like that happens to all of us

[pjp]

I know, I was just particularly annoyed because there isn't a lot I can learn from it. I wasn't even noticing that part of the code, despite using it and checking that it was "working." I suppose coming up with cleaner / easier to read logic helped convince me that it wasn't a persistent logic problem. It wasn't until I confirmed (again) that the function received the argv string correctly that I looked more closely at the error value. I had previously even noticed that the value was being ignored, leaving it at the initialized zero. But "it was the logic error" causing that failure.

I suppose my lesson learned is to improve at evaluating code to be clearer and becoming more proficient at rewrites. I had already not liked that entire function, but was only having problems with one section.
_________________
Quis separabit? Quo animo?

[szatox]

The lesson here is:
"Always initialize variables"

I've recently stumbled over some video on rules for programming space devices - things which must not fail, because nobody's driving there to unbrick them.
Well, I'm not THAT much of a programmer, so not sure how well the whole list fares, but one of said rules said "declare variables in the smallest scope possible".

[Hu]

I agree with minimal scope, but I would argue that always initializing a variable is actually counterproductive. You are better off only initializing the variable when you have a useful value to assign to it, and enabling compiler warnings to detect when the variable might be used uninitialized. I've dealt with buggy programs where the bug was that the variable was initialized at declaration, usually to zero, then never given a real value later. Since the variable was initialized, the compiler did not warn that it was read back without being given a meaningful value. If the variable had been written only when a real value was available, the compiler could have warned when it found a path that read an uninitialized value.

[pjp]

[Hu]

Assuming we are discussing C/C++, modern compilers can warn if the compiler proves the existence of a path which will read a local variable without first writing to it. Initializing the variable to any placeholder value, whether 0 or DEADBEEF, convinces the compiler that the variable has been written, and prevents it from warning about a read-before-write because it sees a write and cannot determine that this write is not useful. Initializing at declaration is fine when the initialization value is useful, but counterproductive if the value is a placeholder you intended to replace on every path through the function. In the latter case, writing to the variable only when you have something useful to put there helps the compiler warn you about paths where you failed to write anything useful.

For programs where you omit an initialization at declaration, I prefer to have it omitted unconditionally, and rely on compiler warnings to prevent you ever releasing a build where the variable is uninitialized. Recent compilers have an option to generate a hidden initialization for such variables, and since it is generated by the compiler, it does not count as a "write" for the purpose of the read-before-write warning, which only considers writes that are actually visible in the source code.

[stefan11111]

Couldn't you have just used atoi or strtol?
If you don't want to use errno, just check if when the function returns 0, it's because of an error, or because it's actually 0.

[GDH-gentoo]

[pjp]

[pjp]

[pjp]

[pjp]

[stefan11111]

[no101]

In my opinion, where you went wrong was initializing the struct to the OK condition rather than the error condition. You can return the struct at any time and it has a proper error value. If you forget to clear the error flag when you set the result value, you can immediately see that proper input returns an error.

My approach would be to use an "out parameter" and only return the error/success. Something like

[szatox]

[Hu]

Agreed, there are ways to write the program such that leaving out initialization causes you problems the compiler fails to catch. For example:

[no101]

[GDH-gentoo]

[no101]

[pjp]

[C5ace]

pjp:

I use 'getopt_long()'.
See example from glibc source:

[pjp]

[pjp]

[pjp]