Better than I was expecting when I saw the mention of the Excel file. I was thinking it would actually open the file at runtime (using the bare minimum hackiest-possible code that "works", of course, not a proper robust Excel reader library) and look up the error number dynamically.

There was the communications software package for the natural gas pipeline control room. It seems there were microwave towers at compression stations along that pipeline's 3 megameter (2000 mile) path. There were two guys in the control room, always alert, not fresh-out-of-school. One of them had a face that showed evidence of having been burned.

The messages were, if remember right, 16 bytes long followed by a four-byte CRC code. Stuff like "station id, subsystem id, component id, sensor id, measurement. The contractor was sorting out some sort of big-endian / little-endian hassle in the device driver.

The development coordinator gave the contractor (me) a test message to test the new comm device driver.

I've never seen two guys move so fast as those control room guys. By the time the coordinator could say "it's a test" they had helicopters in the air and fire trucks rolling from the nearest prairie town.

I guess, when pipeline compressors catch fire, they CATCH FIRE. And the building thermostat survives a few milliseconds longer than other stuff.

Moral of the story. PLEASE include real test data points in your monitoring system design.

Using Excel to generate code is not always a WTF. I've found it useful for generating static LCD screen bitmap array code for embedded products. Using '0' and '1' in the cell and conditional formatting on the value to color the cell gives you the visual. Then use another tab with concatenate and bin2hex formulas to generate the arrays. Export that tab as a CSV file and copy/paste into the .c file with the rest of the code.

it's not that difficult to generate binary tables, in the lsb column you fill the first two cells with "0" and "1", mark the two values, copy-paste it, mark the 4 values, copy-paste, repeat. (alternatively, just type 0, down, 1, down, ...)

it gets easier with the higher bits (you can drag the 0 a bunch of times, then the 1 a bunch of times, then start copy-pasting)

i'd say that table cost him less time than it would have been for him learning bit-magic (although knowing bit-magic might have helped him in other points of his carreer later)

Well, it says: "You might do this for 254 rows of data. Which, as a note, the range of possible values is 255, so guess what was causing the error?" In fact, he did it for 255 rows, and the range of possible values (not only error values) is 256.

So he did present an off-by-one error making another off-by-one error in the posting. (If this is reposted 254 more times, there will be no rows left ...). Kind of like Muphry's law of off-by-one errors. I suggest we call it Murph's law.

(PS: Wow, only 2 reCAPTCHA screens today! And I also made an off-by-one error in my input there, apparently they don't really care what you click, just keep you busy for a while ...)

In blatantly hazardous systems like gas pipelines (and, in fact, most industrial systems, but gas pipelines transport potentially explosive materials), there are no obviously wrong values.

Just like there are no lights that light up to tell you there's a fault. A light that goes out to tell you there's a fault can also tell you that the light itself is faulty (in particular, it can tell you that the filament is broken). A light that lights up to tell you there's a fault cannot tell you that there is also a fault with the light that stops it lighting up.

Pause for a moment to consider a problem: you receive a byte containing an set of flags to represent an error code.

I'm confused. Are you receiving an error code, or a set of flags? They are two different things. Flags are usually checked by using masks, such as if (flags & 0x01) { /* handle flag one / } whereas error codes are checked by value, such as if (err == ENOENT) { / handled noent error */ } I don't see how bitshifting makes sense to determine which bits are set.. it just leaves you with an ugly loop.

You know, if I were sending a test message that was "obviously wrong" for an operation where high temperatures were a VERY BAD THING, I would choose a unlikely value that was very LOW. Like zero, or negative, if the variable is signed. Just a tip!

Eh, I use Excel (actually LibreOffice) for generating production code all the time. It's great for generating large lookup tables and repetitive code, and copy/paste them into the source. I then check the .xls files in along with all the other documentation I generate.

of all the attributes i could give to that method, "easiest" is probably not amongst them...

first, you need already a pretty deep understanding of C to know how unions work

second, C has so many "undefined behavior" pitfalls that you can't be sure that this works across all platforms, all endiannesses, all bitwidths, all compilers, ...

third, you're probably on that one platform/endianness/bitwidth/compiler which does things different, and then you're a day deep into debugging why your code doesn't work before you find this spot again. and then you dig another day into barely documented pragmas that make the compiler handle this more to your liking.

I've found the PBM/PPM image formats to be good for this kind of thing. It's got the same format as a C declaration, and gvim has a syntax mode for it so you can visually edit bitmap images with a text editor.

this reminds me of my College project(s): several programs, and the output from the first one becomes the input of the second, etc. i made a small mistake in the first one, which checked to make sure the data was valid, and a field with "month:32" slipped through. (i checked to be sure it was a number and not letters, but forgot to make sure it was in the 1-12 range) so when the second program tried to look up #32 in a 12-field table...CORE DUMP!

Um.... No. The easiest way to do it (because it's self maintaining) is to use bit-fields.

Using an unsigned char as a bitfield is not supported by the C standard, however, some compilers like gcc allow it as an extension. If you compile with the -pedantic flag, you will receive warning messages for using unsigned char type for bitfields: "warning: type of bit-field ‘a’ is a GCC extension [-pedantic] ..." Also, using "a", "b", "c" for bitfield names is not very descriptive. Look through the Linux kernel source. Flags are always compared to predefined masks.

I'm confused. 255 is missing; is that the code for "no errors" or for "every error happened at once"? Seems to me that the former would cause near-continuous problems and the latter shouldn't happen but once in a great while.

So how was it happening infrequently, but often enough to be bothersome?