https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: dev-lang/icon-9.5.22e fails to compile. Discovered on: amd64 (internal ref: gcc15_tinderbox) System: GCC-15-SYSTEM (https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#GCC-15) Info about the issue: https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#CF0003
Created attachment 911844 [details] build.log build log and emerge --info
I looked into this and it appears to be that compiler is generating a false report. The line that is being reported: ipp.c:88:17: error: initialization of ‘char * (*)(void)’ from incompatible pointer type ‘char * (*)(char *)’ [-Wincompatible-pointer-types[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wincompatible-pointer-types]] 88 | { "define", define }, | ^~~~~~ ipp.c:88:17: note: (near initialization for ‘pplist[0].func’) Here is the code in context that is being reported: ==== ... static char * define (char *s); ... struct ppcmd { char *name; char *(*func)(char *); } pplist[] = { {"define", define}, <<< line 88 ... }; ... static char *define(char *s) { char c, *name, *val; ... }
are you sure you reduced that correctly? also, note that this is a c23 thing: () vs (void) both mean the same thing in c23
(In reply to Sam James from comment #3) > are you sure you reduced that correctly? also, note that this is a c23 > thing: () vs (void) both mean the same thing in c23 Yes. Using the "define" function (the one being reported with this ticket) The declaration and definition for "define" is a static function returning a char * and takes a single char * as its parameter. The structure ppcmd defines the member "func" as a function returning a char * and taking a single char * as its parameter. Here is a copy/paste of the area in question: static int ppopen (char *fname); static char * rline (FILE *fp); static void pushdef (cdefn *d); static void pushline (char *fname, long lno); static void ppdir (char *line); static void pfatal (char *s1, char *s2); static void skipcode (int doelse, int report); static char * define (char *s); static char * undef (char *s); static char * ifdef (char *s); static char * ifndef (char *s); static char * ifxdef (char *s, int f); static char * elsedir (char *s); static char * endif (char *s); static char * errdir (char *s); static char * include (char *s); static char * setline (char *s); static char * wskip (char *s); static char * nskip (char *s); static char * matchq (char *s); static char * getidt (char *dst, char *src); static char * getfnm (char *dst, char *src); static cdefn * dlookup (char *name, int len, char *val); struct ppcmd { char *name; char *(*func)(char *); } pplist[] = { { "define", define }, { "undef", undef }, { "ifdef", ifdef }, { "ifndef", ifndef }, { "else", elsedir }, { "endif", endif }, { "include", include }, { "line", setline }, { "error", errdir }, { 0, 0 }};
I wonder if it's the: 0, 0 that marks the end?
Yeah, you might be right. That said, when I tried to reproduce it, I couldn't as I hit various other C23-related issues. Maybe it's better to just build it with -std=gnu17.
Using -std=c23 (and several others) causes build failures due to library functions that are part of the POSIX standard, but not part of the c23 standard. Using -std=gnu17 does seem like the safe bet
Pushed commit to add -std=gnu17. PR also has an update to metadata.xml to add the remote-id to satisfy pkgcheck.
