This is the mail archive of the gcc-patches@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]

Re: [gfortran] PATCH Fix PR 18537


Tobias Schlüter wrote:
> Since the discussion on comp.lang.fortran seems to have come to an end, I
> think we can try to figure out the right behavior WRT tabs.

I recognize that my opinion may not weigh for much, but here are my
opinions nonetheless:

> In my opinion, the right thing would be this:
> - if no additional options are given, we deal with tabs as-is.  I.e. accept
> tabs everywhere and treat them as synonymous to blanks, except in the first
> six columns of a fixed-form source file, where they skip to column 7, and in
> character-literal-constants, where they're translated to something like ACHAR(9)

Agree.

> - if -Wall is used, we warn for tabs that are used outside of comments

I can agree with that.  I would prefer warning for tabs inside comments
as well, however; there _is_ a line-length limit even in free-form
source, and the interaction of tabs in comments with this length limit
is somewhat unclear.

I also would like a specific option (-Wtabs or somesuch) to turn on just
this warning.

> - if -std=f95 is used we issue an error, if a tab is used in a place where a
> blank is required, IOW we treat it as a graphic character.  Declaring it a
> control character would be contrary to the principle of least surprise,
> according to which I would expect the compiler to accept tabs in comments or
> character-literal-constants.

I don't think I agree with this.  If we treat tab as a graphic
character, I find no justification in the standard for not considering
it to be another representation of "blank" as far as syntax is
concerned.

(Personally, I think that treating tab as a graphic character is itself
surprising, as it is the only graphic character which does not have a
consistent graphical representation in a monospace font.  I also find
that the "principle of least surprise" would lead me to expect the
compiler _not_ to accept tabs in character-literal constants, as they
tend to have surprising behavior when placed there (i.e., the content of
the constant does not match what I see on screen).  Thus, personally I'm
in favor of treating tabs as control characters.)

- Brooks


-- 
The "bmoses-nospam" address is valid; no unmunging needed.


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