[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1003986 [1/2] - in /subversion/trunk/subversion: libsvn_client/ libsvn_fs_base/ libsvn_fs_base/bdb/ libsvn_fs_fs/ libsvn_ra_local/ libsvn_ra_neon/ libsvn_ra_serf/ libsvn_ra_svn/ libsvn_repos/ libsvn_subr/ libsvn_wc/ mod_authz_svn/ mod_...

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Mon, 04 Oct 2010 17:06:55 +0100

On Mon, 2010-10-04 at 11:14 -0400, Greg Hudson wrote:
> On Mon, 2010-10-04 at 06:14 -0400, Julian Foad wrote:
> > The NULL macro is intended for use as a pointer.
>
> Only when statically cast to the appropriate pointer type. This happens
> automatically in many contexts, such as assignments or prototyped
> function parameters. But it does not happen automatically for variable
> parameters of a stdarg function.
>
> So apr_pstrcat(foo, bar, NULL) really is invalid C code.

Ah. In that case, I retract my request for reversion.

> It's not a
> practical concern because common platforms use a single pointer
> representation, but it's a fair warning for a compiler to give.

The issue at hand is when NULL is defined as an unadorned '0' *and* is
passed to a variadic function such as apr_pstrcat. If that's not a
practical concern, that must be because the size and representation of
(int)0 is the same as (char *)0. If that is true on all supported
platforms, then omitting the casts is a valid option; otherwise, we need
them.

Experience suggests it has been fine on all supported platforms to date.

- Julian
Received on 2010-10-04 18:07:54 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.