------- 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