For C and C++, identifiers beginning with underscore and upper case letter or with two underscores are reserve to the implementation. C++ uses _Z for mangling.
Maybe Fortran could prepend "_F". Something beginning with an underscore seems like a much better choice, given the rules about reserved identifiers. Thanks, David On Wed, Oct 3, 2012 at 5:00 PM, Tobias Burnus <bur...@net-b.de> wrote: > David, > > > David Edelsohn wrote: >> >> I am not sure why you chose a period and how best to correct this. > > > Well, in principle any name which the user cannot enter would do. (Not > enter: At least not as valid Fortran identifier.) > > The reason for choosing "." is that <dot><var_name> is used elsewhere in > gfortran for such identifier for the string-length variable belonging to > <var_name>, e.g. "._result" in trans-decl.c. I assume the reason that it > didn't pop up with those is that those are local variables, but I wouldn't > be surprised if it would break elsewhere. > > I wonder whether "@" would work, otherwise, one could also use "_". The only > other problem is that it will break the ABI. On the other hand, it's a > rather new feature and if we bump the .mod version number, the chance that > one effectively forces the user to re-compile is rather high. So far we > always bumped the .mod version number as something changed. There are also > some other patches pending which effectively lead to a bump in the .mod > version. > > (The .mod version won't affect code which doesn't use modules such as > BLAS/LAPACK or any Fortran 66/77 code, but those won't be affected by the > ABI change anyway as there the name doesn't propagate as it does with > modules..) > > > Thanks for investigating the test-suite failure. > > Tobias
