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

Re: svn commit: r15370 - in branches/python-bindings-improvements/subversion/bindings/swig: python/libsvn_swig_py python/svn

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2005-07-20 18:10:48 CEST

Daniel Berlin <dberlin@dberlin.org> writes:

> On Tue, 2005-07-19 at 23:00 +0100, Philip Martin wrote:
>> djames@tigris.org writes:
>>
>> > +static char *poolAttribute = (char *) "_pool";
>> > +static char *assertValid = (char *) "assert_valid";
>> > +static char *emptyTuple = (char *) "()";
>>
>> Casting away const is generally a bad idea, how about
>
> It's not just a bad idea, it doesn't actually do anything.

It allows a subsequent function call to compile without a warning.

> IE the compiler is free to ignore any store to something it knows was
> originally const qualified.

In this case the pointers are passed to a function that is compiled in
a different translation unit, one that's part of the Python binary.
When compiling that function the compiler obviously has no knowledge
of the code above so it cannot determine whether the pointer points to
something that was originally const.

> (C99 6.7.3: "If an attempt is made to
> modify an object defined with a const-qualified type through use of an
> lvalue with non-const-qualified type, the behavior is undefined")
>
> In this case, all compilers i'm aware use the behavior "ignore the
> attempt" :)

I just try to avoid such casts, if they don't exist there is no need
to consider whether they are correct. In this case I assume that the
function PyObject_GetAttrString doesn't ever attempt to write through
the pointer-to-non-const, so it's all a bit academic :)

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 20 18:11:40 2005

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.