[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: how to test for a prototype difference
From: |
Thomas Klausner |
Subject: |
Re: how to test for a prototype difference |
Date: |
Sat, 17 May 2014 19:07:02 +0200 |
On Fri, May 16, 2014 at 11:19:58AM -0400, Nick Bowler wrote:
> Some comments...
Thanks.
> On 2014-05-16 02:33 +0200, Thomas Klausner wrote:
> > Hi Eric!
> >
> > On Wed, Apr 30, 2014 at 06:51:23PM -0600, Eric Blake wrote:
> > > On 04/30/2014 06:12 PM, Thomas Klausner wrote:
> [...]
> > > > I'd like to test for the difference int <-> size_t in a configure
> > > > script so I can get integer type/sign conversion-warnings free code on
> > > > all these operating systems.
> > > >
> > > > I'm however not sure how to do this. Does anyone have a suggestion?
> [...]
> > Here's what I came up with:
> > AC_CACHE_CHECK([parameter type for backtrace()],
> > [am_cv_proto_backtrace_type],
>
> The am_cv_ prefix is used by Automake so I suggest choosing a
> different one.
What do you suggest using as prefixes?
> > [AC_COMPILE_IFELSE(
> > [AC_LANG_PROGRAM(
> > [[
> > #include <execinfo.h>
> > extern
> > #ifdef __cplusplus
> > "C"
> > #endif
> > size_t backtrace(void **addrlist, size_t len);
> > ]])
> > ],
> > [am_cv_proto_backtrace_type=size_t],
> > [am_cv_proto_backtrace_type=int])
>
> So if the compilation fails for any reason, you set the type to int.
> That could be OK in your case (depending how you use it) but it seems
> a little weird to me.
I have a separate backtrace() test before that:
AC_SEARCH_LIBS([backtrace], [execinfo], [
AC_DEFINE([HAVE_BACKTRACE], [1], [Define to 1 if you have the `backtrace'
function.])
], [])
I could make the backtrace type test have three results, int, size_t,
and FAILED, but I'm not sure if it really would serve a purpose. What
kind of errors do you expect?
> > ])
> > AC_DEFINE_UNQUOTED([backtrace_t], [$am_cv_proto_backtrace_type],
> > [Define to return type for backtrace().])
>
> Note that POSIX reserves identifiers ending in _t if you include any
> header file, so you should normally avoid using that suffix in an
> application.
Ok, thanks for the note. Suggestions on how to improve it?
Thomas