cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: yangtse: curl/lib sendf.c,1.125,1.126 sendf.h,1.33,1.34

From: Yang Tse <yangsita_at_gmail.com>
Date: Tue, 27 Mar 2007 04:03:30 +0200

2007/3/25, Dan Fandrich wrote:

> Great! I don't see any reason why that duplicate original section of macros
> in sendf.h needs to be kept around any more in that case.

Well, its the plain old matter with platforms that lack autotools support.

As it is currently in revision 1.39 of curl/lib/sendf.h the first
block is used for platforms that have autotools support, or even not
having it, someone has manually defined HAVE_VARIADIC_MACROS_C99 or
HAVE_VARIADIC_MACROS_GCC for some specific compiler version in a
specific platform config file.

None manually defined at this moment, but they should be defined in
platform specific config files for specific compiler versions if
variadic macro support exists.

So the second block is there to make this transition less troublesome,
and as a very good fallback method, checking for __STDC_VERSION__ or
__GNUC__ when no autotools, config.h, support is available.

This arises another point. In case --disable-verbose is used and the
compiler does not support variadic macros the definition that will be
used is "#define infof (void)" which can give plenty of warnings as
"left-hand operand of comma expression has no effect".

I think it is better to just use "#define infof Curl_infof" in case no
variadic macro support is available, while making a Curl_infof() empty
body in case --disable-verbose is used.

In this case lots of strings might get finally into the code, but at
least with no warnings. It could happen that even when using "#define
infof (void)" the strings would make their way into the code with old
compilers which lack variadic macro support.

So if no one says anything in a couple of days against this last
change I'll commit it then.

--
-=[Yang]=-

Received on 2007-03-27