On Sun 24 Jul 2016 04:38, Eli Zaretskii <e...@gnu.org> writes:
>> > --- libguile/null-threads.h~0 2016-01-02 13:32:40.000000000 +0200
>> > +++ libguile/null-threads.h 2016-07-15 17:47:37.101375000 +0300
>> > @@ -43,7 +43,7 @@
>> > #define scm_i_pthread_create(t,a,f,d) (*(t)=0, (void)(f), ENOSYS)
>> > #define scm_i_pthread_detach(t) do { } while (0)
>> > #define scm_i_pthread_exit(v) exit (EXIT_SUCCESS)
>> > -#define scm_i_pthread_cancel(t) 0
>> > +#define scm_i_pthread_cancel(t) (void)0
>> > #define scm_i_pthread_cleanup_push(t,v) 0
>> > #define scm_i_pthread_cleanup_pop(e) 0
>> > #define scm_i_sched_yield() 0
>>
>> I think not, sorry :/ pthread_cancel returns an int, so
>> scm_i_pthread_cancel should always return an int.
>
> Then code which ignores the value should cast to void.
That way leads to madness :) There are many function call sites in Guile
that ignore the function return values. GCC does not warn about them,
and rightly so. The problem here is that the "null" definition of
scm_i_pthread_cancel is a bare expression and for some reason GCC is
treating this case differently. The solution AFAIU is to make the null
definition of scm_i_pthread_cancel into a function so that it is more
like the proper definition. That way not only will GCC not warn, but it
will also do type checking for us.
Applied a fix along these lines; a --without-threads configuration
builds without warnings and passes all tests for me now.
Andy
