[Libcdio-devel] [PATCH] libcdio 0.79: cd-paranoia enum comparison bugs

[R. Bernstein]

I've committed this change, but really it seems there's a flaw or type
inconsistency in libcdio's revision of cdparanoia that gcc is picking
up for the first time.

In libcdio the that type getting cast in the callback is a
paranoia_cb_mode_t, a postitve integer from 0...12. In cdparanoia, the
type is int. Appearenly cdparanoia (and presumably libcdio's version)
augments the enumeration (in paranoia.h) with two values below
0. Given the string names, these indicate "wrote" and "finished". Boy
do I hate clever coding like this.

If someone wants to take a whack at straightening this out, I'd
appreciate. 

Eric Shattow writes:
 > In at least gcc 4.2.3 compiler, enums fail the cd-paranoia comparison to
 > integers.
 > 
 > src/cd-paranoia/cd-paranoia.c:
 > 
 >   if(callscript)
 >     fprintf(stderr,"##: %d [%s] @ %ld\n",
 > -            
 > function,(function>=-2&&function<=13?callback_strings[function+2]:
 > 
 > +            function,
 > +
 > ((int)function>=-2&&(int)function<=13?callback_strings[function+2]:
 >                       ""),inpos);
 > 
 > The observable problem is that "cd-paranoia -e" output lacks the 2nd data
 > parameter (read/wrote/verify...)
 > 
 > I suspect that the enum types are promoted to an unsigned integer in the
 > comparison, and yet signed in the printf use of "%d". Thus, it would always
 > be "##: 0 [] @ 871416" and never "##: 0 [read] @ 871416". Casting to int
 > does the trick, but this is potentially a problem throughout the cd-paranoia
 > code, as enum types are promoted differently than literal values (#define's
 > which work fine from enum-less xiph cd paranoia code).
 > 
 > I spotted that one above, are there more? How to find them?
 > 
 > Eric
 >