Not all "pedantic" compiler warnings are made equal

IMO, "pedantic" compiler warnings are for the large part evil. Or at very best, very very annoying in most cases. Just like lawyers seem to find some kind of masochistic satisfaction gleaning over twisted nests of spaghetti-legalese clauses, picking apart code so that it is totally "semantically" correct is just an picky exercise in tedium and pointlessness unless something is going wrong.

Without further ado, let's look at some "pedantic" warnings which I think should be considered harmful to resolve - that is, DO NOT CHANGE CODE THAT CAUSES THESE!
DISCLAIMER: you may need to research your compiler's documentation to identify which warnings equate the the ones being referenced here.

1) "Unterminated enum"
Perhaps this is best illustrated with a little code example...

typedef enum eChannelType {

    CHANNEL_TYPE_NONE = 0,

    CHANNEL_TYPE_BIGBAD,

    CHANNEL_TYPE_MESSYMIDDLE,

    CHANNEL_TYPE_SMALLSLOT,

} eChannelType;

As you can see, the last item in the list still has a comma, even though "there isn't any entry following it". I can understand that compiler designers may consider that this is a "harmful" indicator of potentially corrupted or incomplete code that a warning should be generated about to remind forgetful coders.

This causes "batch-edit specialists" (BSI's from herein) to speculate that it probably generates "weird code". Now, I'll admit that I don't know exactly whether compilers in general do anything special in these cases. But it's fair to say that they probably don't.

However, as I see it, this particular construct is to be encouraged, and is in fact really desirable! Remember the first thing I said about this construct ("there isn't any entry following it")? Well, of course there isn't anything there NOW, but we're leaving the door open for MORE entries to easily be added in future. By NOT having this in there, you:
1) add a few more steps to your coding workflow everytime you add new entries to this list (especially when using a "sane" text editor - i.e. exhibit 1 and exhibit 2 - with the single-hotkey "duplicate line" tool) as you can just copy the line above and modify without having to append a comma to the line above
2) bloat your svn diff's, as instead of just highlighting the new item you added, the old end of list also has to get modified to include a ",". This makes it more difficult to track down problematic changes, as it adds another line that must be checked character-by-character to discover potentially problematic changes.
3) potentially cause problems when you forget to add a comma to the end of the of "end of list" line, and then have to find the code again later to add this back in when trying to compile.

Remember, software is fortunately/unfortunately a very "malleable" quantity, so anything that makes modifying it for future uses easier should be better.

EDIT: After further investigation, apparently this is only in the C99 not C89 standard, even though every compiler I've seen is perfectly happy with the C99 version. Perhaps it's time that I start tagging all my C-code as C99 ONLY, and that strictly C89 only compilers should have died out a decade ago :P

2) "Pointers not cast"
Let's consider another code example first

A *a = ...some instance of A...

printf("ptr = %p\n", a);

Now, sometimes pedantic compilers will tell you that this is "bad", and that you need to do
printf("ptr - %p\n", (void *)a);

Again, I can understand that compiler designers have to try to design their software for a wide variety of coder skill-levels and "head-in-sand-idioticy-moment-ratings". Having said that, this sort of pedantic nonsense complaining, where we're clearly just doing a harmless "superclass <- subclass" type assignment is yuck!

Especially in simple cases like this: explicitly doing this cast doesn't make one iota of difference, other than being bloat. Why? Well, here you only care about where the pointer points. The type of pointer doesn't come into this - it only does when you go past the base address the pointer points at, looking for "member" data.