[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: R. Bernstein
Subject: [Libcdio-devel] [PATCH] libcdio 0.79: cd-paranoia enum comparison bugs
Date: Fri, 18 Jan 2008 21:16:21 -0500

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]