Daryle Walker wrote:
In this case, we would have a bug in the decoding and encoding routines. The bug would be that they don't match. If the coding routines are calling the standard library (like I think they are for text archives of primitive types), then the bug is from the standard library not being symmetric. I think the standard library is supposed to give symmetric text I/O
I don't know what the standard library is supposed to do. But the fact is that at least some implementations of he standard library are not handling text i/o symetically in at least two cases: uninitialized bools. floating/double NaN, +/- inf, etc.
so how much effort should we do to work around such bugs?
actually, the effort for uninitialized bool is pretty trivial and I've incorporated and assertion into the appropriate spot. For the others, its a little more work. If someone has enough interest to actually make and test the changes, I'll be happy to receive them, check them, and incorporate them in to the code. I would expect that only some small changes in ??text_i/oprimitive would be necessary. Oh it would be a bad idea to post them to the list. Personally, I'm of the view trying to serialize a NaN would probably a be bug in user code. I'm aware that not everyone would agree with this. Maybe throwing an exception might be enabled/dissabled with another flag applied at archive open time (like no_header, etc). Any way, its not a big issue for me. Presumably, if someone has interest he can submit his improvements and we can discuss it then.
Reading from an uninitialized variable, like what could happen in the original case during encoding, is not a problem any library can fix. The programmer just has to be non-sloppy.
lol - and further more, if we catch him doing something like this we should make sure we don't tell him so he get his deserved punishment!!!!
I think in the case reported by Paul, he's not necessarily using the unitialised value, as its an object that is kind of like a discriminated union. I think this usage parallels the idea of NaN's etc in floating point. I'd expect these to be read back in too, as you suggested.
The problems are not in parallel. For a discriminated union, it is the responsibility of the coding author to determine which fields are active and only read/write those particular fields and skip the inactive fields. The unusability of NaN values is from a high-level perspective, such values are still valid objects from a low-level view. (And the high-level view is just an opinion; some programmers might want to keep NaNs around as a flag.)
This articulates my view. I used the term "overloading" as in semantic overloading where we might use NaN to mean something specific. I can see where this might be useful in some narrow contexts but I would generally consider it an error prone practice. Just one man's opinion. Robert Ramey