Daniel Berlin <dberlin@dberlin.org> writes:
> On Wed, 2005-07-20 at 17:10 +0100, Philip Martin wrote:
>> Daniel Berlin <dberlin@dberlin.org> writes:
>>
>> > 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.
>
> This is a very bad assumption to make, since a lot of compilers have
> whole-program modes now (including gcc), and can discern info from
> libraries and how the library functions are attributed.
> Assuming things like this is an very very very bad idea.
I'm not sure exactly how your argument relates to the code in
question. The Subversion code looks something like this:
extern void python_fn(char *);
static char *name = (char*)"value";
void subversion_fn()
{
python_fn(name);
}
I'm not Python expert but as far as I know that gets built into a
shared object and then the python binary loads the shared object
dynamically and resolves python_fn to an address in the python binary.
When building the python binary from the Python source code the
compiler, even in whole-program mode, cannot take any notice of the
Subversion code, the Subversion code might not even have been written
when the Python binary is compiled! If python_fn in the python binary
attempts to write through that pointer-to-non-const it seems extremely
unlikely that the compiler will be able to ignore the write just
because the object pointed to is really const.
--
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 19:44:04 2005