Re: svn commit: r1535399 - in /subversion/trunk/subversion: libsvn_fs_fs/ libsvn_fs_x/ libsvn_subr/ libsvn_wc/ mod_authz_svn/ tests/cmdline/ tests/libsvn_client/ tests/libsvn_fs_fs/ tests/libsvn_fs_x/ tests/libsvn_subr/ tests/libsvn_wc/

On 25.10.2013 11:50, Branko Čibej wrote:
> On 25.10.2013 11:40, Philip Martin wrote:
>> Branko Čibej <brane_at_wandisco.com> writes:
>>
>>> Sideline: *IF* we, as a community, agree to do this, then: (a) the rule
>>> should be documented in HACKING, and (b) there should be a '#define
>>> NULLPTR ((void*)0)' or reasonable facsimile in either svn_types.h or
>>> svn_private_config.h. I really do not want to see '(char*)NULL' all over
>>> the place. That's ... unsightly.
>> That would be incompatible with C++ since (void*) doesn't automatically
>> convert to (char*) by default.
> You do realize that this is entirely irrelevant for varargs, don't you?
>
>> I'd like to avoid such incompatibilities
>> because I'd like to be able to use a C++ compiler at some point to catch
>> things like enum mismatches. I suppose we could have NULLCHARPTR for
>> variadic functions expecting (char*) which is the common case.
> For all I care it can be ((intptr_t)0) which will always be the correct
> size and can always be converted to a null pointer constant. But I'm
> also pretty sure that we definitely do not want to use this special
> constant in anything but varargs. Maybe call it VA_NULL, to make the
> intent more mnemonic.

Even better:

#define VA_NULL ((struct svn_fake_and_never_defined*)0)

You can put this into a variable argument list, but not assign it to a
pointer variable or argument of a known type.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com