* scm_t_subr warnings
@ 2013-02-24 21:00 Julian Graham
2013-03-01 9:01 ` Ludovic Courtès
0 siblings, 1 reply; 2+ messages in thread
From: Julian Graham @ 2013-02-24 21:00 UTC (permalink / raw
To: guile-devel
Hey Guilers,
Andy and Ludo and I were discussing this on IRC and it was suggested
that we move the question to the mailing list. I'm trying to compile
some code -- using `gcc -pedantic' -- that invokes `scm_c_make_gsubr',
and I'm getting the following warning:
warning: ISO C forbids passing argument 5 of ‘scm_c_make_gsubr’
between function pointer and ‘void *’ [-pedantic]
/usr/local/include/guile/2.0/libguile/gsubr.h:63:13: note: expected
‘scm_t_subr’ but argument is of type ‘struct scm_unused_struct *
(*)(struct scm_unused_struct *, struct scm_unused_struct *)’
I was confused, because I was sure that Guile defines scm_t_subr as
`SCM (*) ()', meaning that an `scm_t_subr' is of unspecified arity.
And I was right, but only at libguile compilation time. From __scm.h:
#ifdef BUILDING_LIBGUILE
typedef SCM (* scm_t_subr) ();
#else
typedef void *scm_t_subr;
#endif
Thus the warning: ISO C lets you cast any kind of pointer to `void *'
-- except for a function pointer. Ludovic suggested that this bit of
preprocessor magic exists to support C++, in which the `()' style of
function prototyping is equivalent to `(void)'. But that leaves people
like me who want to be, well, pedantic, in a tough spot. Is there
anything we can do about this? One thing I was thinking was that we
could support the C++ case (and others) more explicitly. E.g.:
#ifdef __cplusplus
typedef void *scm_t_subr
#else
typedef SCM (* scm_t_subr) ();
#endif
What do you think?
Regards,
Julian
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: scm_t_subr warnings
2013-02-24 21:00 scm_t_subr warnings Julian Graham
@ 2013-03-01 9:01 ` Ludovic Courtès
0 siblings, 0 replies; 2+ messages in thread
From: Ludovic Courtès @ 2013-03-01 9:01 UTC (permalink / raw
To: guile-devel
Hello,
Julian Graham <joolean@gmail.com> skribis:
> Andy and Ludo and I were discussing this on IRC and it was suggested
> that we move the question to the mailing list. I'm trying to compile
> some code -- using `gcc -pedantic' -- that invokes `scm_c_make_gsubr',
> and I'm getting the following warning:
>
> warning: ISO C forbids passing argument 5 of ‘scm_c_make_gsubr’
> between function pointer and ‘void *’ [-pedantic]
> /usr/local/include/guile/2.0/libguile/gsubr.h:63:13: note: expected
> ‘scm_t_subr’ but argument is of type ‘struct scm_unused_struct *
> (*)(struct scm_unused_struct *, struct scm_unused_struct *)’
>
> I was confused, because I was sure that Guile defines scm_t_subr as
> `SCM (*) ()', meaning that an `scm_t_subr' is of unspecified arity.
> And I was right, but only at libguile compilation time. From __scm.h:
>
> #ifdef BUILDING_LIBGUILE
> typedef SCM (* scm_t_subr) ();
> #else
> typedef void *scm_t_subr;
> #endif
The rationale is given above in gsubr.h:
/* The type of subrs, i.e., Scheme procedures implemented in C. Empty
function declarators are used internally for pointers to functions of
any arity. However, these are equivalent to `(void)' in C++, are
obsolescent as of C99, and trigger `strict-prototypes' GCC warnings
(bug #23681). */
(This refers to <http://savannah.gnu.org/bugs/?23681>.)
It is still an obsolescent feature as of C11.
Would it work for you to just cast the argument to scm_t_subr? This is
what snarf.h (and guile-snarf) does.
> Thus the warning: ISO C lets you cast any kind of pointer to `void *'
> -- except for a function pointer.
[...]
> #ifdef __cplusplus
> typedef void *scm_t_subr
> #else
> typedef SCM (* scm_t_subr) ();
> #endif
>
> What do you think?
I think it’s not just C++, but also future C standards and current
‘-Wstrict-prototypes’.
We can test for C++ or C > 11, but there’s no way do test for
-Wstrict-prototypes or -pedantic. There’s #pragma GCC diagnostic, but
it cannot be used here.
So my current recommendation would be to add an explicit cast to
scm_t_subr, unless someone has a better idea.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2013-03-01 9:01 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-02-24 21:00 scm_t_subr warnings Julian Graham
2013-03-01 9:01 ` Ludovic Courtès
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).