From: Alan W. I. <ai...@us...> - 2004-01-07 00:55:05
|
I just knocked off two items today (fortran command-line parsing, and the changed Fortran API) so as far as I know that leaves just three items discussed recently on list which I believe should be dealt with before the release. * fortran single precision.... (I plan to do this tomorrow) * Mac OS X and OSF1 issues with pthreads locking the application so you could not ctrl-c out of it. I believe Joao is investigating further. * OSF1 f77 issues with three of the fortran examples. Two of these are just compatibility issues and might be resolved by Joao linking in an additional fortran compatibility library for OSF1. (At least this is how I have solved similar problems on other systems.) One of these is a much more serious double-underscore naming convention problem which I have asked Joao to investigate further for OSF1 f77 to see if this can be resolved by an f77 option. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: <jc...@fe...> - 2004-01-07 01:56:35
|
On Wednesday 07 January 2004 00:54, Alan W. Irwin wrote: | I just knocked off two items today (fortran command-line parsing, and the | changed Fortran API) so as far as I know that leaves just three items | discussed recently on list which I believe should be dealt with before the | release. | | * fortran single precision.... (I plan to do this tomorrow) | | * Mac OS X and OSF1 issues with pthreads locking the application so you | could not ctrl-c out of it. I believe Joao is investigating further. I don't know if I will have the time to do it. If I don't, we must ship with pthreads disabled by default. | | * OSF1 f77 issues with three of the fortran examples. Two of these are | just compatibility issues and might be resolved by Joao linking in an | additional fortran compatibility library for OSF1. (At least this is how I | have solved similar problems on other systems.) One of these is a much more | serious double-underscore naming convention problem which I have asked Joao | to investigate further for OSF1 f77 to see if this can be resolved by an | f77 option. The same as above. But I don't understand why this specific function has the problem, while others don't. Could it be because the function name is soo long? Just occurred to me just now... Joao | | Alan | __________________________ | Alan W. Irwin | email: ir...@be... | phone: 250-727-2902 | | Astronomical research affiliation with Department of Physics and | Astronomy, University of Victoria (astrowww.phys.uvic.ca). | | Programming affiliations with the PLplot scientific plotting software | package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the | Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project | (lbproject.sf.net). | __________________________ | | Linux-powered Science | __________________________ | | | ------------------------------------------------------- | This SF.net email is sponsored by: IBM Linux Tutorials. | Become an expert in LINUX or just sharpen your skills. Sign up for IBM's | Free Linux Tutorials. Learn everything from the bash shell to sys admin. | Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ai...@us...> - 2004-01-07 04:58:25
|
On 2004-01-07 01:56-0000 Jo=E3o Cardoso wrote: > On Wednesday 07 January 2004 00:54, Alan W. Irwin wrote: > | I just knocked off two items today (fortran command-line parsing, and = the > | changed Fortran API) so as far as I know that leaves just three items > | discussed recently on list which I believe should be dealt with before= the > | release. > | > | * fortran single precision.... (I plan to do this tomorrow) > | > | * Mac OS X and OSF1 issues with pthreads locking the application so yo= u > | could not ctrl-c out of it. I believe Joao is investigating further. > > I don't know if I will have the time to do it. If I don't, we must ship w= ith > pthreads disabled by default. Rafael, please disable by default, and if Joao has time to look further and find a solution for OSF1 and Mac OS X he can enable again by default. > | > | * OSF1 f77 issues with three of the fortran examples. Two of these are > | just compatibility issues and might be resolved by Joao linking in an > | additional fortran compatibility library for OSF1. (At least this is h= ow I > | have solved similar problems on other systems.) One of these is a much = more > | serious double-underscore naming convention problem which I have asked = Joao > | to investigate further for OSF1 f77 to see if this can be resolved by a= n > | f77 option. > > The same as above. > > But I don't understand why this specific function has the problem, while > others don't. Could it be because the function name is soo long? Just > occurred to me just now... No, it is because it has an embedded underscore in its name. The various Unix fortran compiler vendors saw yet another chance to be different in the way they treat such names. Some add one underscore to the name, some add two. (To quote Maurice, BARF, and those are my feelings as well.) Accordin= g to g77 info the latter option is more prevalent so that is the g77 default. So the specific question for Joao (man f77 on your OSF1 system) is whether there is an f77 option to add a second underscore. The equivalent (default) option for g77 (see info g77) is -f-second-underscore. Does f77 have an option (probably named different) that does that? If Joao finds no such option for OSF1 f77 or if anybody is concerned there will be a fortran vendor out there who doesn't follow the double underscore convention even as an option, then another way to get out of this mess is t= o ban embedded underscores in function names in the common API. Only 3 functions have that problem now, pl_setcontlabelformat, pl_setcontlabelparam, and plcalc_world. We could simply change their names to plsetcontlabelformat, plsetcontlabelparam, and plcalcworld =3D=3D> fortr= an API problem solved. If this is the consensus decision, then I would need a second decision on whether it is worthwhile to preserve the old names for backwards compatibility. These are all functions that have been introduced fairly recently, and it would be nice to get rid of them completely to avoid adding to the cruft. I definitely need help in making the correct decisions here starting with Joao looking for any options having to do with underscores in his OSF1 f77 man page. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Maurice L. <mj...@ga...> - 2004-01-07 07:03:22
|
Alan W. Irwin writes: > If Joao finds no such option for OSF1 f77 or if anybody is concerned there > will be a fortran vendor out there who doesn't follow the double underscore > convention even as an option, then another way to get out of this mess is to > ban embedded underscores in function names in the common API. Only 3 > functions have that problem now, pl_setcontlabelformat, > pl_setcontlabelparam, and plcalc_world. We could simply change their names > to plsetcontlabelformat, plsetcontlabelparam, and plcalcworld ==> fortran > API problem solved. If this is the consensus decision, then I would need a > second decision on whether it is worthwhile to preserve the old names for > backwards compatibility. These are all functions that have been introduced > fairly recently, and it would be nice to get rid of them completely to > avoid adding to the cruft. I personally don't have an attachment to the old (w/ embedded underscore) names, and getting rid of them would be a simple, clean solution. -- Maurice LeBrun |
From: Alan W. I. <ai...@us...> - 2004-01-07 05:57:22
|
On 2004-01-06 16:54-0800 Alan W. Irwin wrote: > * fortran single precision.... (I plan to do this tomorrow) Actually, I finished this tonight. configure --without-double turned up one C++ example compile problem under these conditions (which shows how little we use this single-precision option any more) and a MAINTAINERCLEAN that should have been CLEAN (for the generated *.f files in examples/f77). Once those problems fixed, libraries were built properly, the examples built without problems, and valgrind ran without problems on one of the more complicated fortran examples that had been converted to single-precision with double2single.sed. Also, the single-precision fortran examples look good (although diff's with their double-precision cousins show differences as you would expect.) > > * Mac OS X and OSF1 issues with pthreads locking the application so you > could not ctrl-c out of it. Since Joao has no time, I hope Rafael takes care of this immediately by making pthreads not the default. > > * OSF1 f77 issues with three of the fortran examples. Two of these are just > compatibility issues and might be resolved by Joao linking in an additional > fortran compatibility library for OSF1. (At least this is how I have solved > similar problems on other systems.) One of these is a much more serious > double-underscore naming convention problem which I have asked Joao to > investigate further for OSF1 f77 to see if this can be resolved by > an f77 option. As I said in other e-mail I need help here fairly urgently with both man results for OSF1 f77 and the API decision making on the underscored function names. It would be nice to get this wrapped up in the next day or so, so that Rafael's next snapshot is a real release candidate with no changes contemplated (unless bug fixes need doing) until release. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2004-01-07 07:47:14
|
"Alan W. Irwin" wrote: > > On 2004-01-06 16:54-0800 Alan W. Irwin wrote: > > > * fortran single precision.... (I plan to do this tomorrow) > > Actually, I finished this tonight. configure --without-double turned up one > C++ example compile problem under these conditions (which shows how little > we use this single-precision option any more) I have a real need for it though ;) As for the underscore problem: I know that Burkhard Burow who developed the tool "cfortran.h" ran into this same problem (it seems to originate with f2c, a FORTRAN 77 to C translation program). His recommendation is to use the C side of the interface to solve the issue (it is well beyond the capabilities of C preprocessors). So you need to define either a macro with the trailing double underscores or to define an extra C routine which just calls the version with a single one ... Given the current set-up (Fortran programs call stubs to the actual C routines) it should be simple to solve this: for these compilers: #define FNAMEU(x,y) y##__ otherwise: #define FNAMEU(x,y) y##_ This introduces an extra STUB_LINKAGE case, but it keeps the Fortran names identical to the C ones. Regards, Arjen |
From: Alan W. I. <ai...@us...> - 2004-01-07 17:13:54
|
On 2004-01-07 08:46+0100 Arjen Markus wrote: > Given the current set-up (Fortran programs call stubs to the actual C > routines) > it should be simple to solve this: > > for these compilers: > #define FNAMEU(x,y) y##__ > > otherwise: > #define FNAMEU(x,y) y##_ > > This introduces an extra STUB_LINKAGE case, but it keeps the Fortran > names > identical to the C ones. This solution is not correct because the actual behaviour of the fortran compilers is more complicated: if there is an embedded underscore then append two underscores, otherwise append one. With this convention, "hello_world" maps to "hello_world__" while "helloworld" maps to "helloworld_". The above solution would map every name to a double underscore suffix. I have thought better of my earlier suggestion to remove the embedded underscore from the 3 names that have it. That is a lot of work for each of our language interfaces, libplplot itself, the ninth examples for each of the interfaces, and the documentation. All this change would be bound to introduce bugs. However, I have thought of a straightforward solution in the night. Simply define two variations of the underscored names. #define PLCALC_WORLD FNAME(PLCALC_WORLD,plcalc_world) #define PLCALC_WORLDa FNAME(PLCALC_WORLD,plcalc_world_) with two separate definitions of PLCALC_WORLD and its alternate: void PLCALC_WORLD(PLFLT *rx, PLFLT *ry, PLFLT *wx, PLFLT *wy, PLINT *window) { c_plcalc_world(*rx, *ry, wx, wy, window); } void PLCALC_WORLDa(PLFLT *rx, PLFLT *ry, PLFLT *wx, PLFLT *wy, PLINT *window) { c_plcalc_world(*rx, *ry, wx, wy, window); } This repetition only has to occur 3 times for the 3 names with embedded underscores so it is not that bad. (However, we should be careful from now on not to make the problem worse by banning any further names in the common API with embedded underscores.) g77 continues to work with these changes, and I have comitted them to cvs. Joao, can you compile x09f now on OSF1 f77? If so, I think (since Rafael has put off writing additional perl/PDL examples and documenting that interface) we are ready for our first actual release candidate on the Unix side of things with no more code changes considered until release (except for bug fixes). Documentation changes will be welcome right up to very near the release day, of course. That leaves the various windows variations to consider. Vince, is sys/win-tk ready for a release? Andrew, is sys/dos/djgpp ready for release? Arjen, as discussed elsewhere, please send your changes for sys/win32/msdev to me as a patch (or patches) which you would like me to apply. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-01-07 09:06:07
|
* Alan W. Irwin <ai...@us...> [2004-01-06 20:58]: > Rafael, please disable by default, and if Joao has time to look further and > find a solution for OSF1 and Mac OS X he can enable again by default. Hey, come on boy, are you that lazy? :-) It is a one-line patch: --- configure.ac 6 Jan 2004 21:25:41 -0000 1.147 +++ configure.ac 7 Jan 2004 09:04:14 -0000 @@ -79,7 +79,7 @@ with_rpath=yes with_nobraindead=no with_freetype=yes -with_pthreads=yes +with_pthreads=no with_qhull=yes with_csa=yes with_ltdlsystem=no Done in CVS. -- Rafael |
From: Alan W. I. <ai...@us...> - 2004-01-07 16:14:11
|
On 2004-01-07 10:01+0100 Rafael Laboissiere wrote: > * Alan W. Irwin <ai...@us...> [2004-01-06 20:58]: > > > Rafael, please disable by default, and if Joao has time to look further and > > find a solution for OSF1 and Mac OS X he can enable again by default. > > Hey, come on boy, are you that lazy? :-) It is a one-line patch: It is a well-known fact that the best programmers are lazy....:-) Seriously, though, I asked you to do it in this case because you may have had a different opinion/solution or wanted more tests before making the decision. Anyhow, I am glad this pthreads issue won't hurt anybody now until a more definitive solution can be obtained post-release. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-01-07 11:14:13
|
* Alan W. Irwin <ai...@us...> [2004-01-06 16:54]: > I just knocked off two items today (fortran command-line parsing, and the > changed Fortran API) so as far as I know that leaves just three items > discussed recently on list which I believe should be dealt with before the > release. > > [...] I just stepped down and abandoned the release goals regarding the PDL bindings. The goals list is then the one you posted. I will have limited time for PLplot development from now until the end of January so I think that, besides your own changes and fixes, the final release tarball will not differ that much from the current cvs tarball. Please tell me when you think you are done with your projects and I will start the release process. I think I will need at least a period of one week of CVS freeze. -- Rafael |
From: Alan W. I. <ai...@us...> - 2004-01-08 00:11:38
|
On 2004-01-07 12:09+0100 Rafael Laboissiere wrote: > Please tell me when you think you are done with your projects and I will > start the release process. I am finished with my fortran work, and that concludes the "known issues" in the subject line. PLplot now needs to be tested. Thus, I think the next step in the release process is for you to generate a tarball for all the developers and testers (including our Mac OS X testers) to try to make sure all our fixes actually do what is intended for the exact set of autotools versions that you use and for the wide variety of platforms available to us. (Probably autotools version variations are not quite so important as they used to be, but nevertheless we have been burned by this issues a number of times, and therefore I would still prefer to spend my testing time on a tarball as close as possible to the final version, i.e., created with your particular [Debian-patched] set of autotools versions.) Testing by Debian users will be useful as well as a complement to wide testing on various platforms so I am glad you will be issuing Debian packages at the same time you release the next tarball. I understand from your personal e-mail to me that it will be roughly a week before you can create, check, and issue a tarball and Debian packages (real life has intervened on your time). That timing is fine with me, but I thought everybody on this list should be informed of that timing as well. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-01-08 08:33:31
|
* Alan W. Irwin <ai...@us...> [2004-01-07 16:11]: > I understand from your personal e-mail to me that it will be roughly a week > before you can create, check, and issue a tarball and Debian packages (real > life has intervened on your time). That timing is fine with me, but I > thought everybody on this list should be informed of that timing as well. I will be off town the next days and will not be able to produce a new cvs release tarball before next Wednesday, January 14. I apologize for the inconvenience. That tarball will be a *_real_* release candidate, but I will produce at least another one a week later (around January 21) in which all the copyright/license notices will be checked/updated. If everything goes well, PLplot 5.3.0 will be released in three weeks from now, hopefully. I would ask you to not put HEAD in a bad state during the present month, so please hold on with your revolutionary projects until February. Otherwise, I will have to make a branch for the release. That is feasible, but means much more work for me. Any objections? -- Rafael |
From: <jc...@fe...> - 2004-01-07 16:31:42
Attachments:
f77.1
|
On Wednesday 07 January 2004 04:58, Alan W. Irwin wrote: | On 2004-01-07 01:56-0000 Jo=E3o Cardoso wrote: | > On Wednesday 07 January 2004 00:54, Alan W. Irwin wrote: | > | I just knocked off two items today (fortran command-line | > | parsing, and the changed Fortran API) so as far as I know that | > | leaves just three items discussed recently on list which I | > | believe should be dealt with before the release. | > | | > | * fortran single precision.... (I plan to do this tomorrow) | > | | > | * Mac OS X and OSF1 issues with pthreads locking the application | > | so you could not ctrl-c out of it. I believe Joao is | > | investigating further. | > | > I don't know if I will have the time to do it. If I don't, we must | > ship with pthreads disabled by default. | | Rafael, please disable by default, and if Joao has time to look | further and find a solution for OSF1 and Mac OS X he can enable again | by default. | | > | * OSF1 f77 issues with three of the fortran examples. Two of | > | these are just compatibility issues and might be resolved by Joao | > | linking in an additional fortran compatibility library for OSF1.=20 | > | (At least this is how I have solved similar problems on other | > | systems.) One of these is a much more serious double-underscore | > | naming convention problem which I have asked Joao to investigate | > | further for OSF1 f77 to see if this can be resolved by an f77 | > | option. | > | > The same as above. | > | > But I don't understand why this specific function has the problem, | > while others don't. Could it be because the function name is soo | > long? Just occurred to me just now... | | No, it is because it has an embedded underscore in its name. The | various Unix fortran compiler vendors saw yet another chance to be | different in the way they treat such names. Some add one underscore | to the name, some add two. (To quote Maurice, BARF, and those are my | feelings as well.) According to g77 info the latter option is more | prevalent so that is the g77 default. So the specific question for | Joao (man f77 on your OSF1 system) is whether there is an f77 option | to add a second underscore. The equivalent (default) option for g77 | (see info g77) is -f-second-underscore. Does f77 have an option | (probably named different) that does that? | | If Joao finds no such option for OSF1 f77 or if anybody is concerned | there will be a fortran vendor out there who doesn't follow the | double underscore convention even as an option, then another way to | get out of this mess is to ban embedded underscores in function names | in the common API. Only 3 functions have that problem now, | pl_setcontlabelformat, The only reference in the manual is: =2Dassume nounderscore Does not append a trailing underscore character to=20 external user-defined names: the main program name, named COMMON,=20 BLOCK DATA, and names implicitly or explicitly declared=20 EXTERNAL. The name of blank COMMON remains _BLNK__, and Fortran=20 intrinsic names are not affected. The default is -assume=20 underscore. But this doesn't apply. If I remove the trailing undescore in plstubs.h, then everything (x09f)=20 works OK. So, Digital F77 doesn't treat names with an underscore differently then=20 other names. To avoid problems I would remove the underscore, and take=20 the oportunity to rename the functions to a sorter name, using other=20 existing functions as a model. I enclose the f77 manual page, just "nroff -man f77.1 | less" Joao | pl_setcontlabelparam, and plcalc_world. We could simply change their | names to plsetcontlabelformat, plsetcontlabelparam, and plcalcworld | =3D=3D> fortran API problem solved. If this is the consensus decision, | then I would need a second decision on whether it is worthwhile to | preserve the old names for backwards compatibility. These are all | functions that have been introduced fairly recently, and it would be | nice to get rid of them completely to avoid adding to the cruft. | | I definitely need help in making the correct decisions here starting | with Joao looking for any options having to do with underscores in | his OSF1 f77 man page. | | Alan | __________________________ | Alan W. Irwin | email: ir...@be... | phone: 250-727-2902 | | Astronomical research affiliation with Department of Physics and | Astronomy, University of Victoria (astrowww.phys.uvic.ca). | | Programming affiliations with the PLplot scientific plotting software | package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), | the Loads of Linux Links project (loll.sf.net), and the Linux | Brochure Project (lbproject.sf.net). | __________________________ | | Linux-powered Science | __________________________ | | | ------------------------------------------------------- | This SF.net email is sponsored by: IBM Linux Tutorials. | Become an expert in LINUX or just sharpen your skills. Sign up for | IBM's Free Linux Tutorials. Learn everything from the bash shell to | sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=CCk | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ai...@us...> - 2004-01-07 17:25:58
|
On 2004-01-07 16:29-0000 Jo=E3o Cardoso wrote: Thanks for digging through the man page for anything relevant on underscore= s. Indeed, it looks like your Dec fortran compiler does not follow the "double-underscore for embedded underscore" convention. > If I remove the trailing undescore in plstubs.h, then everything (x09f) > works OK. I now supply both variations of the 3 names so your compiler should now be happy. But please do the test again with current cvs just to make sure. > To avoid problems I would remove the underscore, and take > the oportunity to rename the functions to a sorter name, using other > existing functions as a model. I think that is a good idea (which Maurice supported as well), but frankly = I will probably never have time/energy for it so it will have to be someone else post-release who is willing to do all the detail work involved. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: <jc...@fe...> - 2004-01-07 19:36:09
|
On Wednesday 07 January 2004 17:25, Alan W. Irwin wrote: | On 2004-01-07 16:29-0000 Jo=E3o Cardoso wrote: | | Thanks for digging through the man page for anything relevant on | underscores. Indeed, it looks like your Dec fortran compiler does not | follow the "double-underscore for embedded underscore" convention. | | > If I remove the trailing undescore in plstubs.h, then everything | > (x09f) works OK. | | I now supply both variations of the 3 names so your compiler should | now be happy. But please do the test again with current cvs just to | make sure. I will have to wait for a tarball, I don't have all needed tools in that=20 machine. Jaoo |
From: Arjen M. <arj...@wl...> - 2004-01-08 07:20:28
|
"Alan W. Irwin" wrote: > > On 2004-01-07 08:46+0100 Arjen Markus wrote: > > > Given the current set-up (Fortran programs call stubs to the actual C > > routines) > > it should be simple to solve this: > > > > for these compilers: > > #define FNAMEU(x,y) y##__ > > > > otherwise: > > #define FNAMEU(x,y) y##_ > > > > This introduces an extra STUB_LINKAGE case, but it keeps the Fortran > > names > > identical to the C ones. > > This solution is not correct because the actual behaviour of the fortran > compilers is more complicated: if there is an embedded underscore then > append two underscores, otherwise append one. With this convention, > "hello_world" maps to "hello_world__" while "helloworld" maps to > "helloworld_". The above solution would map every name to a double > underscore suffix. > I am sorry, I was unclear: I meant the introduction of an additional macro, for names with underscores: In the ordinary case: #define FNAME(x,y) y##_ #define FNAMEU(x,y) y##_ and if embedded underscores introduce two underscores at the end: #define FNAME(x,y) y##_ #define FNAMEU(x,y) y##__ > > Arjen, as discussed elsewhere, please send your changes for sys/win32/msdev > to me as a patch (or patches) which you would like me to apply. > Yes, I will do that (one last thing to check is the issue of tmpfile()). Sending the patches in the format you asked should be no problem. Regards, Arjen |