Thread: gcc warning regarding void*

  1. #1
    Registered User
    Join Date
    May 2008
    Posts
    11

    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)

  2. #2
    Registered User C_ntua's Avatar
    Join Date
    Jun 2008
    Posts
    1,853
    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

  3. #3
    Registered User
    Join Date
    May 2008
    Posts
    11
    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.
    Last edited by OriginalCopy; 12-07-2008 at 02:34 PM.

  4. #4
    Registered User C_ntua's Avatar
    Join Date
    Jun 2008
    Posts
    1,853
    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

  5. #5
    Registered User
    Join Date
    May 2008
    Posts
    11
    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.
    Last edited by OriginalCopy; 12-07-2008 at 03:05 PM.

  6. #6
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,336
    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?

  7. #7
    Registered User
    Join Date
    May 2008
    Posts
    11
    Quote Originally Posted by tabstop View Post
    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.

  8. #8
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 10
    Last Post: 07-10-2008, 03:45 PM
  2. Screwy Linker Error - VC2005
    By Tonto in forum C++ Programming
    Replies: 5
    Last Post: 06-19-2007, 02:39 PM
  3. <Gulp>
    By kryptkat in forum Windows Programming
    Replies: 7
    Last Post: 01-14-2006, 01:03 PM
  4. Dikumud
    By maxorator in forum C++ Programming
    Replies: 1
    Last Post: 10-01-2005, 06:39 AM
  5. Interface Question
    By smog890 in forum C Programming
    Replies: 11
    Last Post: 06-03-2002, 05:06 PM

Tags for this Thread