[Bug fortran/46405] New: Preprocessor generated code can exceed 132 characters

[Bug fortran/46405] New: Preprocessor generated code can exceed 132 characters

[w6ws at earthlink dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46405

           Summary: Preprocessor generated code can exceed 132 characters
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: w6ws@earthlink.net


A silly, but nonetheless interesting, problem - it is easy to exceed the
132 character line limit when using preprocessing.  The specific case that
is causing me problems is error handling code where one would like to use the
predefined __FILE__ macro (along with __LINE__) to record the area of code
reporting a problem.  The code might reside in a deeply nested directory
path, and absolute file names are used by the make files.

Some musings:

1.) The built-in preprocessor is supposedly Fortran-aware.  E.g., it knows
about
things like // being character concatenation, and not a C/C++ inline comment.

2.) By the Principle of Least Astonishment, a user might expect that as long
as the source code presented to the compilation system (e.g., preprocessor +
compiler proper) conforms to the 132 character limit, things should be ok.
A user sees __FILE__ as being only 8 characters, yet invisibly, the compiler
sees it very differently and refuses to compile his code.

3.) This is a problem with macros in general, and not just __FILE__.

4.) This is a problem with a lot of other Fortran compilers - not just
gfortran.

5.) Yes, one can use the -ffree-line-length-none option.  Disadvantage is
that it will not detect other problems in lines that are not affected by
preprocessing.

So it seems to me that one solution would be for the preprocessor to enforce
the 132 character limit (modulo the -ffree-line-length option).  But when the
preprocessed code is presented to the compiler, the overcompiler should
specify -ffree-line-length-none.

[Bug fortran/46405] Preprocessor generated code can exceed 132 characters

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46405

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-11-10 09:06:21 UTC ---
Sounds line a non-trivial problem - though I also have encountered  the issue
with __FILE__. For compiler options (the other case for which I have
encountered the line-length issue), there are now the F2008 intrinsic character
functions compiler_options() and compiler_version().

Regarding the point that CPP knows about Fortran: That's currently not the
case. Thus, gfortran invokes (lib)cpp in the "-traditional" mode which misses
several newer CPP features. See bug 28662.

[Bug fortran/46405] Preprocessor generated code can exceed 132 characters

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46405

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2010.11.14 13:29:39
                 CC|                            |tkoenig at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #2 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2010-11-14 13:29:39 UTC ---
We _could_ set the line length to unlimited when invoking the preprocessor
automagically.

Would this be a good idea?  Hmm...

[Bug fortran/46405] Preprocessor generated code can exceed 132 characters

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46405

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot
                   |                            |gnu.org

--- Comment #3 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2010-11-14 18:54:49 UTC ---
I was thinking this same solution.  But, maybe the user who is having the
problem should just do that. In that case this is not really a bug.  The
problem is not knowing this is the problem.  Is there a flag we can check and
just not truncate at 132 or whatever length if CPP?

[Bug fortran/46405] Preprocessor generated code can exceed 132 characters

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46405

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-11-14 19:16:10 UTC ---
(In reply to comment #2)
> We _could_ set the line length to unlimited when invoking the preprocessor
> automagically.
> Would this be a good idea?  Hmm...

I do not think that that's the proper solution. In that case you do not
distinguish between lines which are genuine too long and those which are only
too long due to the macro processing. I think if you want to have the latter,
you need to plug into libcpp and add a line-length check there.

Then, you can as a second step disable the line length check in the front-end
itself. 

(In reply to comment #3)
> I was thinking this same solution.  But, maybe the user who is having the
> problem should just do that.

I think that's the cleanest solution. After all, even if the line length is
only exceeded due to the CPP macro, it is still invaid Fortran.

> Is there a flag we can check and
> just not truncate at 132 or whatever length if CPP?

Well, there is gfc_cpp_enabled().

[Bug fortran/46405] Preprocessor generated code can exceed 132 characters

[dfranke at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46405

Daniel Franke <dfranke at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfranke at gcc dot gnu.org

--- Comment #5 from Daniel Franke <dfranke at gcc dot gnu.org> 2010-12-16 00:14:01 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > I was thinking this same solution.  But, maybe the user who is having the
> > problem should just do that.
> 
> I think that's the cleanest solution. After all, even if the line length is
> only exceeded due to the CPP macro, it is still invaid Fortran.

Same here. Close as INVALID/WONTFIX?

[Bug fortran/46405] Preprocessor generated code can exceed 132 characters

[dfranke at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46405

Daniel Franke <dfranke at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

[Bug fortran/46405] Preprocessor generated code can exceed 132 characters

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46405

--- Comment #6 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2011-01-08 22:59:45 UTC ---
Author: tkoenig
Date: Sat Jan  8 22:59:42 2011
New Revision: 168604

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168604
Log:
2011-01-08  Thomas Koenig  <tkoenig@gcc.gnu.org>

    PR fortran/46405
    * invoke.texi:  Mention -ffree-line-length-none and
    -ffixed-line-length-none for preprocessing.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/invoke.texi

[Bug fortran/46405] Preprocessor generated code can exceed 132 characters

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46405

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |FIXED

--- Comment #7 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2011-01-08 23:01:25 UTC ---
Recommendation mentioned in documentation, closing.