[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: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2005-07-20 19:50:00 CEST

On Wed, 2005-07-20 at 18:43 +0100, 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.

You are assuming we do no runtime recompilation or optimization when
shared libs are loaded, etc.
This is not really as far off as you think.

See, for example, LLVM (http://llvm.cs.uiuc.edu).
Which, btw, the pypy guys have a backend for.

I'm just saying that making assumptions about what the compiler can and
can't see, at *any* time, is a bad move, because compiler technology
will bite you in the ass for doing it eventually.

---------------------------------------------------------------------
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:50:48 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.