autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AC_COMPUTE_INT's arguments


From: Stepan Kasal
Subject: Re: AC_COMPUTE_INT's arguments
Date: Mon, 4 Sep 2006 18:30:19 +0200
User-agent: Mutt/1.4.2.1i

Hello,

On Sun, Sep 03, 2006 at 10:00:08AM +0200, Ralf Wildenhues wrote:
> * Stepan Kasal wrote on Sat, Sep 02, 2006 at 02:41:48PM CEST:
> > On Sat, Sep 02, 2006 at 12:09:49PM +0200, Ralf Wildenhues wrote:
> > > * Bruno Haible wrote on Fri, Sep 01, 2006 at 02:05:26PM CEST:
> >
> > What about introducing
> > AC_LANG_BOOL_COMPILE_IFELSE(prologue, bool-expr, if-true, if-false)
> > 
> > as a public macro?  (We would document that it is implemented only for
> > the three C languages.)
> 
> Probably a good idea.

OK, I hope to implement AC_LANG_BOOL_COMPILE_IFELSE and
AC_LANG_COMPUTE_INT soon.

> > > But that public version would have to include the cast to long int,
> > > for the HP compiler, which would be at least a bit ugly. 
> > 
> > Ralf, could you please give me a reference to the problem?
> 
> See the comment in the implementation of AC_CHECK_SIZEOF.

Well, it only says that `sizeof(foo) >= 0' has problems.

I do not see what workaround is needed for `sizeof (ptrdiff_t) <=
sizeof (int)', if any.  Perhaps
  (long int) sizeof (ptrdiff_t) <= (long int) sizeof (int) ?
I do not think that we want
  (long int) (sizeof (ptrdiff_t) <= sizeof (int))

> [...] I wonder though whether casting an expression
> of some integer type that is either true or false, to long int is
> really a limitation (but maybe I remember the problem wrongly).

I do not think this is the workaround needed by HP, see above.

> > (My naive opinion is that we should not give up the clean API for
> > a problem with a particular vedor.)
> 
> IMHO that's the wrong way around.  Autoconf is all about existing
> limitations and bugs, and its API tries to capture or wrap what is
> portably possible.

I'm not sure there is a contradiction.  Anyway, I would suggest to
modify ptrdiff_max.m4 to use
AC_LANG_BOOL_COMPILE_IFELSE([sizeof (ptrdiff_t) <= sizeof (int)])
and wait for a bug report.

Does that sound reasonable?

> > But I wonder whether it is worth it to have a special name for a
> > trivial and natural combination of two macros.
> > Perhaps AC_CACHE_CHECK_INT could be dropped?
> 
> * Paul Eggert wrote on Sat, Sep 02, 2006 at 11:23:53PM CEST:
> > It is a close call.  It does capture a common pattern, which is used
> > twice within Autoconf itself and could be used in Gnulib (in the
> > stdint module).  But if there's sentiment to drop it, now's the time.

One usage in Gnulib does not mean it is worth it to enlarge the
Autoconf manual by the description of this macro.
The two usages in Autoconf are not direct indication that this is the
way it will be used outside.

OTOH, it is good to encourage to use this combination, as oposed to
a silent call to AC_COMPILE_INT (or AC_LANG_COMPILE_INT).

OK, no one has a strong opinion here, let's keep Paul's macro.  (Up
to possible rename.)

Stepan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]