config.h.dist:
224 typedef void MySignalHandler;
so when main.c:
1793 MySignalHandler(*prevtrap) ();
it actually says
1793 void(*prevtrap) ();
so it is a pointer to a function returning void with unspecified
parameters.
The error is
proto.h:678:50: note: expected 'void (*)(int)' but argument is of type
'MySignalHandler (*)(void)' {aka 'void (*)(void)'}
for proto.h:
678 extern void (*mySignal(int signal_number, void (*action) (int))) (int);
So the new-found unhappiness is about formerly "unspecified" arguments
(which is not entirels the same as foo(void) ) being compatible with the
effective foo(int) as defined in proto.h.
And as usual once you know what it is you can easily find it.
The gcc-15 porting guide mentioned this here:
https://gcc.gnu.org/gcc-15/porting_to.html#c23-fn-decls-without-parameters
We could go back to std17 like in so many cases or just more surgical
change these few defintions to be correct. Either would work, let me
look what looks less confusing...
Signal handlers might be not needed the way they are there (see the fork
commit), but in most places they are already defined in a better style with
"SIGNAL_ARG" as the argument.
using config.h.dist:
225 #define SIGNAL_ARG int _dummy
The newer definition looks like
MySignalHandler(*volatile prevtrap) (SIGNAL_ARG) = NULL;
It is having the parameters defined, using the header for the type,
marking it volatile to not rely on it without refetch and explicit in
assigning a non-good initial value.
That seems a smaller diff for now until the project decides to follow the fork
or not.
Even smaller than setting std17 to get some modernisms :-)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2125182
Title:
FTBFS with gcc15 in Questing
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/w3m/+bug/2125182/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
