public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/46405] New: Preprocessor generated code can exceed 132 characters
@ 2010-11-10  1:30 w6ws at earthlink dot net
  2010-11-10  9:06 ` [Bug fortran/46405] " burnus at gcc dot gnu.org
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: w6ws at earthlink dot net @ 2010-11-10  1:30 UTC (permalink / raw)
  To: gcc-bugs

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.


^ permalink raw reply	[flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-01-08 23:01 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-10  1:30 [Bug fortran/46405] New: Preprocessor generated code can exceed 132 characters w6ws at earthlink dot net
2010-11-10  9:06 ` [Bug fortran/46405] " burnus at gcc dot gnu.org
2010-11-14 13:39 ` tkoenig at gcc dot gnu.org
2010-11-14 19:10 ` jvdelisle at gcc dot gnu.org
2010-11-14 21:12 ` burnus at gcc dot gnu.org
2010-12-16  0:14 ` dfranke at gcc dot gnu.org
2010-12-27  0:28 ` dfranke at gcc dot gnu.org
2011-01-08 23:16 ` tkoenig at gcc dot gnu.org
2011-01-08 23:35 ` tkoenig at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).