Curious to garner some opinions on how "hacky" the following is.
Code:[ ... ] struct MyStruct x = { { 0, "stuff" }, { 1, "more" }, NULL } ; int main( int argc, char **argv ) { void **ptr ; struct MyStruct *x_ptr ; for( x_ptr = x ; *(ptr=x_ptr) != NULL ; x_ptr++ ) printf( "%s\n", x_ptr->msg ) ; return EXIT_SUCCESS ; } ;
I think you might run into problems with that (but maybe not on your particular computer/compiler setup necessarily). I'm not certain, I've only skimmed it, but I think it's possible that the "0" first element of a struct could, in some cases, be interpreted the same as a NULL in memory. You have no idea howis laid out in memory and so you could end up terminating the loop early because it thinks it's hit a NULL pointer when in fact it's just hit a zero.Code:{ 0, "stuff" }
Question: Why not just use a "0" index in a fake struct entry to be your EOR indicator, and number from 1 instead, e.g.:
Code:{1, "stuff"}, {2, "more}, {0, ""};
- Compiler warnings are like "Bridge Out Ahead" warnings. DON'T just ignore them.
- A compiler error is something SO stupid that the compiler genuinely can't carry on with its job. A compiler warning is the compiler saying "Well, that's bloody stupid but if you WANT to ignore me..." and carrying on.
- The best debugging tool in the world is a bunch of printf()'s for everything important around the bits you think might be wrong.
Thanks for pointing that out. Ironically, the alternative suffers from (essentially) the same problem in that it defines the last entry to be a "null" (and thus assumes that no valid value will conflict). Of course, at least it can be explicit and not subject to platform/compiler variance so may be (generally) a better solution.
My dilemma is that I'm correlating external library variables (the integers) to strings and I don't actually have explicit knowledge of the "unused" values available and so I'm just happy to terminate my static list.
It might be better off to say
An integer of 0 is likely to be valid, but a char pointer of NULL is pretty definitively invalid (you can't print it in any meaningful way).Code:{ 0, NULL }
"" (an empty string) would also work, if you know that all valid entries must be non-empty strings.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
