On 7/17/07, via RT Mark Glines <[EMAIL PROTECTED]> wrote:
# New Ticket Created by Mark Glines # Please include the string: [perl #44009] # in the subject line of all future correspondence about this issue. # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44009 >[07:03] <@particle> there are different warnings on different processors, of course :) [07:43] <@Coke> patches welcome. [07:43] <+purl> That's swahili for "Shut the hell up." So after searching through the build log for a little while, I found some interesting warnings: src/dynext.c: In function `run_init_lib': src/dynext.c:315: warning: cast does not match function type src/dynext.c:322: warning: cast does not match function type The code looks nasty, but innocent: 315: load_func = (PMC * (*)(Interp *))D2FPTR(Parrot_dlsym(handle, cload_func_name)); 322: init_func = (void (*)(Interp *, PMC *))D2FPTR(Parrot_dlsym(handle, cinit_func_name)); But looking at it in the preprocessor, I think gcc's just complaining about casting from one kind of function pointer to another. typedef void (*funcptr_t)(void); ... load_func = (PMC * (*)(Interp *))(funcptr_t)((UINTVAL)(Parrot_dlsym(handle, cload_func_name))); Soo... I dove into the details, found that D2FPTR uses PTR2INTVAL and INTVAL2PTR, so I tried doing the same thing, just passing a better prototype in instead of funcptr_t. load_func = UINTVAL2PTR(PMC * (*)(Interp *), PTR2UINTVAL( Parrot_dlsym(handle, cload_func_name))); gets preprocessed to load_func = (PMC * (*)(Interp *))((UINTVAL)(Parrot_dlsym(handle, cload_func_name))); But, of course, gcc didn't like that either. Since Parrot_dlsym returns a void*, is there any particular reason why we don't just do: load_func = Parrot_dlsym(handle, cload_func_name); init_func = Parrot_dlsym(handle, cinit_func_name); ...which quiets the warnings, and is a hell of a lot easier to read and to maintain? Mark
that's a big, ugly mess of macros. your solution is concise, but void pointers are dangerous and should be avoided wherever possible. it's not a coding standard yet, but it will be *soon*. perhaps there's a solution that's both easier on the eyes, and safer. ~jerry
