GNOME Bugzilla – Bug 623296
Fortran: double question marks can cause error
Last modified: 2018-07-30 10:49:52 UTC
Consider the following Fortran file: program test implicit none write(6,*) '?? some text ??' end When running doxygen on this file the following is seen: Parsing file /home/andy/bug/test.f... ******************************************************************** Error in file /home/andy/bug/test.f line: 6, state: 20 ******************************************************************** This is seen with doxygen 1.7.1 using binary version from the website: doxygen-1.7.1.linux.bin.tar.gz
The problem remains in 1.7.2
I can not reproduce the problem with above test case with current svn (r749), nor with 1.7.2. Please attach a fully self contained test (.f, Doxyfile) that reproduces your problem.
Created attachment 176810 [details] Fortran which results in error The attached Fortran (identical to the source posted originally), results in the following: ~/test> doxygen --version 1.7.2 ~/test> doxygen ... Preprocessing /home/andy/test/test.f... Prepassing fixed form of /home/andy/test/test.f Parsing file /home/andy/test/test.f... ******************************************************************** Error in file /home/andy/test/test.f line: 7, state: 20 ******************************************************************** ... This was using: http://ftp.stack.nl/pub/users/dimitri/doxygen-1.7.2.linux.bin.tar.gz I also see the same problem at SVN r749, built on openSUSE 11.3 (x86_64) with packages from default repositories and ./configure && make
Created attachment 176812 [details] Doxyfile The attached Doxyfile was generated simply with 'doxygen -g', no modifications were made.
Hmm, strangely now I can reproduce it. And you found a trigraph, i.e. "??'" is internally converted to "^", hence the string is never closed. See also: http://en.wikipedia.org/wiki/Digraphs_and_trigraphs#C
(In reply to comment #5) > Hmm, strangely now I can reproduce it. And now I found the reason why: your Doxyfile has preprocessing enabled, mine didn't. The preprocessor unconditionally replaces trigraphs with their corresponding values. For the case shown, one could use double quotes '"' as a work around, or disable preprocessing of the sources.
Thanks, this is interesting, I had no idea about these trigraphs. This code is Fortran77, and it is not preprocessed during compilation. However, our source tree contains C, C++ and Fortran files, so we want Doxygen preprocessing turned on for the C and C++ files. I naively assumed this would cause no problems with the Fortran since there are no preprocessing directives contained within. Perhaps one could instead of simply having an 'ENABLE_PREPROCESSING' variable, also have a 'PREPROCESSING_PATTERNS' variable which could be along the same lines as 'FILE_PATTERNS'? Anyway, I will simply modify our source code to remove the trigraph, and implement a check to avoid ever allowing them to creep into our Fortran code again. Please feel free to close the bug if you decide not to implement any enhancement based on this bug report.
Every parser built into doxygen already has the ability to indicate whether or not C-preprocessing is required (see ParserInterface::needsPreprocessing()). For Fortran this currently returns TRUE. I don't know if there are situations where Fortran code should be preprocessed. But if not then simply returning FALSE would already fix the problem (and still allow C/C++ files to be preprocessed). Daniel: can you have a look?
(In reply to comment #8) > I don't know if there are situations where Fortran code should be preprocessed. > But if not then simply returning FALSE would already fix the problem (and still > allow C/C++ files to be preprocessed). Preprocessing of Fortran sources is not standardized, but common. There is no such thing as a Fortran preprocessor. However, there are many cases where simply a C/C++ preprocessor is used. E.g. GNU fortran uses cpp or libcpp in traditional mode; preprocessing is triggered by the case of extension on platform that support it, i.e. .f90 is not preprocessed, but .F90 is. Same for .f[or] and .F[OR]. And so on. Hence, I'd suggest to leave the preprocessing stuff as is, but introduce an option ENABLE_TRIGRAPHS = YES|NO, default YES to match behavior of earlier versions, to enable/disable trigraph processing. This may come in handy for other languages as well. Btw, cpp of GCC ignores trigraphs by default and only enables them with a flag, see: http://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html#index-trigraphs-946
Yes, we use the distinction, .F and .F90 to be preprocessed, and .f and .f90 to not be preprocessed. All the (recent editions of) compilers I know about automatically do this based on file suffix.
Ok, then the ENABLE_TRIGRAPHS option is a good idea indeed.
As discussed in https://github.com/doxygen/doxygen/pull/734 , Doxygen has moved its issue tracking to https://github.com/doxygen/doxygen/issues All Doxygen tickets in GNOME Bugzilla have been migrated to Github. You can subscribe and participate in the new ticket in Github. You can find the corresponding Github ticket by searching for its Bugzilla ID (number) in Github. Hence I am closing this GNOME Bugzilla ticket. Please use the corresponding ticket in Github instead. Thanks a lot!