This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/42852] gfortran -Wall warns about truncated lines when only a continuation character is truncated



------- Comment #3 from kargl at gcc dot gnu dot org  2010-01-24 00:57 -------
(In reply to comment #2)
> > In other words, fix your code by putting an & in column 72.
> 
> This is not a solution since it makes it invalid fixed-form source:
> 
>     Error: Syntax error in argument list at (1)

Yes, I realized my mistake after I posted.

> Not treating the char-73 & specially makes -Wline-truncation useless in
> projects containing source that is intended to be both fixed and free-form.  I
> realize the note is not normative, and the spec states "If a source line
> contains only default kind characters, it shall contain exactly 72 characters;
> otherwise, its maximum number of characters is processor dependent".  However,
> there are many people formatting code according to note 4.10, especially header
> code provided by libraries.

What?  This is the first bug report about this problem I've seen
in my 7 years of hacking on gfortran.  I  doubt that there are
"many people" formatting their code according to a Note in the
Standard.  Most people don't even have a copy of the Standard.

> Choosing fixed or free-form forces a convention on
> users, and this is really unacceptable.

gfortran supports both fixed and free form.  Choose whatever
form you want.  If you choose to mix the two, then you need
to deal with processor-dependent behavior.

>  So, in lieu of gfortran addressing
> this ticket, the only way for a library to not break its users' ability to use
> -Wline-truncation would be to generate two versions of the header, but this is
> work to maintain and requires users to update all include statements.

So it's gfortran's fault you write non-portable code, and instead
of dealing with it on your end, you think that gfortran developers
should do the work to make your code compile.

I'll note that I stated that I felt it should be closed with a
WONTFIX, but changed it to an enhancement request.  In lieu of receiving
a patch from you to address the issue, someone may someday in the 
distant future, when there are less important bugs to fix, might
address the issue.

The Note in the Standard is assuming a specific behavior for a
processor-dependent behavior.  gfortran currently does not 
assume that specific choice.




-- 


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]