gcc warning regarding void*

Hello folks. While not a complete beginner in C, I still don't understand what causes the warning described below. Here's the relevant piece of code (from the lemon parser generator, part of sqlite):

Code:

void *ParseAlloc(void *(*mallocProc)(size_t)){
  yyParser *pParser;
  pParser = (yyParser*)(*mallocProc)( (size_t)sizeof(yyParser) );
  if( pParser ){
    pParser->yyidx = -1;
#ifdef YYTRACKMAXSTACKDEPTH
    pParser->yyidxMax = 0;
#endif
#if YYSTACKDEPTH<=0
    yyGrowStack(pParser);
#endif
  }
  return pParser;
}

And the way I'm using its return value:

Code:

AST_node* parse_language(scanner_state *state) {
	AST_node *r;
	token_value *token;
	void *pParser;
	int scanner_state;
	size_t lexem_len=0;
	r = ast_malloc_node(top,none,root);
	if(!r) {
		return NULL;
	}
	pParser = ParseAlloc(malloc);
	if(!pParser) {
		free(r);
		return NULL;
	}
	while((scanner_state = scan(state,&token)) > 0) {
		lexem_len++;
		printf("OP: %d token: %d\n",scanner_state,token->i);
		Parse(pParser,scanner_state,token,r);
	}
	ParseFree(pParser,free);
	printf("number of lexems: %d\n",lexem_len);
	return r;
}

Yet it complains about the line which calls ParseAlloc():

warning: assignment makes pointer from integer without a cast

So, since I know what I'm doing, and lemon says a parser should be an opaque type and I shouldn't rely on its current implementation, the first thing I do is to make it shut up by casting the retval of the function to (void*) (even if ParseAlloc() returns a void pointer, I know), yet it still complains:

warning: cast to pointer from integer of different size

DIFFERENT SIZE?

This drives me crazy, I don't understand where the #&*? it gets this from?

I'm using gcc with --version:

Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr --enable-shared --enable-languages=c,c++,fortran,objc,obj-c++,treelang --enable-threads=posix --mandir=/usr/share/man --infodir=/usr/share/info --enable-__cxa_atexit --disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu --disable-libstdcxx-pch --with-tune=generic
Thread model: posix
gcc version 4.3.2 (GCC)

Maybe it's complaining because you return pParser which is the type of pointer to yyParser, which I have no idea what type is? Probably an int?
Two solutions:

Code:

yyParser* ParseAlloc(void *(*mallocProc)(size_t)){
return (void *)pParser;

The first seems better

1. The lemon guys are pretty clear about it: a parser is an opaque type (as such, it should be a void*)
2. I already did that, it results in the same warning:

warning: assignment makes pointer from integer without a cast

I've been scratching my head around this for 50 minutes now, and fixed a bunch of warnings in lemon on the way, but this one is greedy.

Do you have any other suggestion?
I wonder why type casting doesn't work.

Later Edit: yyParser is a struct.

Strange. The warning clearly says that "if you cast correctly I wouldn't exist"
If you want give the whole code and I ll try to compile/debug it

The code is available via svn:
svn checkout http://googlecode.com/svn/trunk/ ypl-read-only

Now keep in mind that the code is pretty immature, as such there's not much error checking/reporting, etc (read: premature optimization).

Thanks.

This is a shot in the dark, but does the compiler see a prototype for ParseAlloc so that it knows it returns void * and not int?

Originally Posted by tabstop

This is a shot in the dark, but does the compiler see a prototype for ParseAlloc so that it knows it returns void * and not int?

I'm so stupid. That was it. Thanks for shooting in the dark

Cheers.

Also, this is a genuine potential bug: If the pointer returned by the function is above 31 bits, then it will go wrong when it's been converted to a poionter again as it will no longer point to the same place as it originally was.

By the way, opaque pointers doesn't have to be void * - you can do something like this:

Code:

// something.h
struct blah;

blah *myfunction();

// something.c
struct blah
{
    // content defined for struct blah
    ... 
};

blah *myfunction()
{
  ... do stuff here 
}

In fact, it is very helpful if you have multiple different opaque types, as there is no risk of confusion between type A and type B structures - which can easily happen if there are several different void * arguments to a set of related functions.

--
Mats