This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

type mismatch in conditional expression...used to compile fine


Hi,

I've tried the below using both gcc 2.95.2 and the 1/3/2001 snapshot of
gcc from codesourcery, I get the same errors with both.
I'm compiling with -Wall.

The main question I have is: Is the conditional operator supposted to
require that the last two operends be of the same type, is there any way
around this with gcc?

My problem revolves around the following situation:

-Basically, I have the following macro directive declared at the head of
my source file:
#define PMAP (MapType == MFF ? ((mff*)pMap) : (MapType == MTF ?
((mtf*)pMap) : ((mtf_MT*)pMap)))


-I also have this named enumeration in my source file:
enum LOADMAP_MAPTYPES
{
   MFF,
   MTF,
   MTF_MT
};

-Finally, one of the functions containing the statements that give me
the error is:
static void* Internal_Action_LoadMap(enum LOADMAP_MAPTYPES MapType, int
fdMapFile, void* pMap)

As you can see from the function parameter list, MapType and pMap are
valid, statements like if(MapType == MFF), etc. are fine, of course.

The problem comes when I have something like
"PMAP->Header.NumProhibitedMTs", using that macro to cast pMap to the
appropriate type, depending on what MapType is set for, and then
dereference it. I faintly remember gcc not giving me warnings/errors
about this when I last touched this code awhile ago...with both of the
gcc's I've tried, I get the following:

shared/map.c:92: warning: pointer type mismatch in conditional
expression
shared/map.c:92: warning: dereferencing `void *' pointer
shared/map.c:92: request for member `Header' in something not a
structure or union

It seems that the conditional operator wants the latter two operands of
the same type, and doesn't like that casting I'm doing. My question is,
is this a gcc-specific feature, or part of the C spec saying I shouldn't
do such a thing. (It might look like an ugly hack I've done, but it does
save me from reproducing a lot of code in this case). Is there a
pragma/switch I can throw to gcc to stop complaining about this, or is
what I'm trying to do considered just plain wrong? I'd really like to
keep using -Wall and stay as compiler-independant as possible...

In my search on the web for some information, I've found few useful
things, most useful being the following thread:

http://gcc.gnu.org/ml/gcc-bugs/2000-07/msg00093.html



Any help is appreciated, maybe I'm just being stupid...

Robby

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]