On Thu, Jan 23, 2025 at 08:16:25AM +0100, Florian Weimer wrote:
> * Jakub Jelinek:
>
> > On Wed, Jan 22, 2025 at 04:57:40PM -0700, Jerry James wrote:
> >> On Wed, Jan 22, 2025 at 4:43 PM Chuck Anderson <cra@xxxxxx> wrote:
> >> > It looks like most (all?) perl XS packages ('C' implementations of Perl functions) are FTBFS with GCC 15. I'm trying to fix perl-Term-ReadLine-Gnu to be C23-compatible. The workaround is to add -std=gnu17 to the CFLAGS which can be done via OPTIMIZE for MakeMaker builds like this:
> >> >
> >> > /usr/bin/perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE="$RPM_OPT_FLAGS -std=gnu17" NO_PACKLIST=1 NO_PERLLOCAL=1
> >> >
> >> > but I don't really know how to fix these the "right" way:
> >>
> >> The issue is that "typedef int XFunction ();" used to say in C17 that
> >> an XFunction returned an int and took an undeclared number and type of
> >> parameters. With C23, that says that an XFunction takes zero
> >> parameters; i.e., it is equivalent to "typedef int XFunction (void);".
> >> Try this patch:
> >
> > This is not correct. Varargs functions like (...) are not compatible
> > with non-varargs functions (so e.g. one which takes (FILE *), etc.).
> > E.g. on x86-64 they have slightly different ABI (the varargs function
> > need %rax to be number of floating point ... arguments) while non-vargs
> > doesn't, but there could be other arches where it is completely ABI
> > incompatible.
>
> GCC used to pretend they were compatible in GCC 14:
>
> void f(int, int);
> void (*g) () = f;
This is not variable arguments (in C17 and earlier), it is unspecified
arguments.
And unspecified arguments is compatible with any non-varargs set of
arguments (which uses just types from after promotion, so not e.g.
char/short/float).
void foo (int, ...);
void bar (int, long, double);
void baz (short, float);
void fred (long, unsigned long long, int);
void corge (void);
void (*fn) ();
void
qux (void)
{
fn = foo;
fn = bar; fn (1, 1L, 1.0);
fn = baz;
fn = fred; fn (1L, 1ULL, 1);
fn = corge; fn ();
}
/tmp/1.c: In function ‘qux’:
/tmp/1.c:12:6: error: assignment to ‘void (*)()’ from incompatible pointer type ‘void (*)(int, ...)’ [-Wincompatible-pointer-types]
10 | fn = foo;
| ^
/tmp/1.c:14:6: error: assignment to ‘void (*)()’ from incompatible pointer type ‘void (*)(short int, float)’ [-Wincompatible-pointer-types]
12 | fn = baz;
| ^
(with both GCC 14 and 15, in 13 and earlier these used to be just warnings).
C23 simply doesn't have a replacement for the unspecified arguments case,
for a good reason, it is a security and maintainability hazard where the
compiler can't check at parsing time whether one passes correct arguments
to the function, because it does not know what the correct arguments to
the function are in that case. And users need to take care of the correct
argument types, see the above testcase with having to distinguish int from
long from long long from double from long double etc.
> The other problem is that C does not have type like void * for function
> pointers (perhaps even two—one for variadic functions, and one for
> non-variadic functions). Within Fedora, void * can serve this purpose,
> but it is not portable. Evidently, programmers and GCC though that
> void (*) () was the function replacement for void *.
For C17 and earlier, void (*) (); was a replacement for functions returning
void and having any non-varargs arguments except the non-promoted one.
That is still not all functions, the return type has to be specified
(there is the implicit int thingy but has been warned about for years
before, (*) () meant non-varargs functions returning int and
non-float/char/short arguments) and varargs is not covered and
float/char/short args are not covered, those really need exactly matching
prototypes.
Jakub
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
