From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10693 invoked by alias); 10 Nov 2010 01:30:58 -0000 Received: (qmail 10680 invoked by uid 22791); 10 Nov 2010 01:30:58 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,T_FRT_FREE X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 10 Nov 2010 01:30:50 +0000 From: "w6ws at earthlink dot net" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/46405] New: Preprocessor generated code can exceed 132 characters X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: w6ws at earthlink dot net X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Wed, 10 Nov 2010 01:30:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-11/txt/msg01230.txt.bz2 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.