Hi Kevin, I understand now. Thanks for the explanation. Ian and I had a look at this code. It appeared to us that the best would be to rename this common block. In fact in this include file, there is two common blocks with bad names. FD and X we propose to rename them D510FD and D510X this should fix your problem. What do you think ?
Cheers, Olivier -----Original Message----- From: Kevin B. McCarty [mailto:[EMAIL PROTECTED] Sent: Monday, June 26, 2006 6:49 PM To: Olivier Couet Cc: [EMAIL PROTECTED]; Ian Mclaren; [EMAIL PROTECTED] Subject: Re: Bug#374978: A problem with PAW variables - looking for suggestions Olivier Couet wrote: > Hi Kevin, > > Quite frankly I am not sure a such protection is needed. Calling a > function X, Y or Z when these keywords are known as reserved ones is > really bad programming, unless the programmer wants to make confusing > code on purpose. Well, let me explain what leads to the symbol "x_" being defined in the scope of Frank's original test case. In that case he did *not* define a FORTRAN function X() in his shared library. For Debian, I compile the CERN libraries both as static libraries and as shared libraries. By default the linker pulls in shared libraries in preference to static libraries. When Frank creates his dynamic library to load into PAW, he links it against libmathlib in order to allow it to use certain functions. In particular it is linked against the shared version of mathlib. But mathlib includes a common block named /X/ (it is defined in the file src/mathlib/gen/d/d510si.inc in Cernlib source code). G77 translates this into a symbol named x_ in the object code. So for any shared lib loaded into PAW which is dynamically linked to mathlib, the COMIS interpreter will find this symbol x_ and try to interpret the "x" in a PAW command "fun1 1 x 100 0 100" as that symbol. (Then it will segfault since x_ is actually a common block and not a function.) You might say this is my own fault for making dynamic versions of CERN libraries available. However this bug can even be triggered with normal CERN static libraries if someone wants to use any of the following mathlib functions that require the common block /X/ to be defined: errorf() fumili() mconv() monito() scal() sgz() Please see the new test case I attach as an example. (You may have to edit the included Makefile for the location of your Cernlibs.) > For instance, in fortran, you can do things like that: > > program then > integer integer, else, endif > integer = 1 > endif = 0 > else = 2 > if (integer .eq. if) then > endif = 3 > else > endif = 2 > endif > end > > It compiles ! but who would like to write such code ? just to make > confusion may be ? FORTRAN is amazing :-) > I am afraid that making a such patch may introduce some side effects > which might be much worst than that. Which is why I ask whether you know of a perhaps better way to fix this? > Is this fix really important for you ? Well, it is important for me but I am happy to keep it as a separate Debian-specific patch if you do not want to include it. (If there do turn out to be other problems with the patch, I will ensure that users know I am to blame, not you guys.) However as I show in the attached test case, there are situations (maybe they are rare?) where users of the official libraries distributed by CERN are affected, not only users of the Debian packages. If you have a better patch that is less likely to affect other parts of PAW, please let me know. > By the way in your patch you have protection for X and Z only, you are > missing Y. I used >= and <= to test that the character is between x and z (or X and Z) in the alphabet, inclusive, so this should also cover Y: + ((procname[0] >= 'x' && procname[0] <= 'z') || + (procname[0] >= 'X' && procname[0] <= 'Z'))) > Also X, Y and Z are not "are PAW internal dummy variables." > they are reserved keywords used to define analytic functions. OK, point taken. My apologies, I am no PAW expert. But this point of terminology doesn't affect the existence of the problem. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/ Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544
