Philip Martin wrote:
> 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.
But unless I'm mistaken, the data pointed to by that
pointer-to-non-const-that-is-really-const can reside
in a page marked read-only, and so if ptyhon_fn attempts
to write through the pointer, it will fall down, go boom.
(Or maybe that is only C++?)
Casting away const _is_ a bad thing... just unavoidable
sometimes in the face of legacy apis that aren't const
correct.
In other words, if subversion_fn() is going to call
python_fn() with const data, it better know that
python_fn() is mis-declared and that it is going
to treat the pointer as const even though it hasn't
promised to do so.
Thanks,
Joseph
---------------------------------------------------------------------
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:53:30 2005