On Wed, Aug 13, 2008 at 09:54:04PM -0700, Dan Fandrich wrote:
> On Thu, Aug 14, 2008 at 03:45:31AM +0200, Yang Tse wrote:
> > Aha! so CURL_CHECK_DEF_INTXX_C is not yet good enough :-(
> >
> > Just redone internals of CURL_CHECK_DEF_INTXX_C and added debug tracing.
> >
> > Committed now. Lets await the results and see if it goes better now.
>
> Not quite there yet...

...and I think I figured out why. I accidentally gave the glibc definition
for __INT64_C in my previous message--here is Open Watcom's definition for
INT64_C:

#define INT64_C(x) (x + (INT64_MAX - INT64_MAX))

Boy, that's going to be fun to parse in m4! It may be easier to parse
INT64_MAX instead and extract the suffix; Watcom defines that as a simple

#define INT64_MAX 9223372036854775807LL

but, surely, that's in itself no more portable.

By the way, immediately before INT64_C in the Watcom header files is this:

/* Constant macros. According to C99 these are only visible in C++ programs
   if __STDC_CONSTANT_MACROS is defined. */
#if !defined(__cplusplus) || defined(__STDC_CONSTANT_MACROS)

so you may want to investigate whether setting __STDC_CONSTANT_MACROS would
ever be necessary.

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved