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


Steve Kargl wrote:
>     For the type character with kind kind-param, if present, and for type
>     default character otherwise, a representable character, rep-char, is
>     one of the following:
>       (1)  Any character in the processor-dependent character set in fixed
>            source form.  A processor may restrict the occurrence of some or
>            all of the control characters.
>       (2)  Any graphic character in the processor-dependent character set in
>            free source form.
> 
> This means we can choose to issue a warning for *any* tab *anywhere*
> in the file, because <tab> is a control character, not a graphic character.

This is interesting, and indeed supports the point of view that a warning is
in place inside a character string.  Unfortunately, you'd still have to
identify comments along the way, which can be come cumbersome especially when
continuation lines get into play.

>>>>expanded in load_line (), so it looks like some reworking is necessary to get
>>>>this warning right, and I don't think it's worth it.
>>>
>>>
>>>What to you mean?  It is not worth issuing a warning?  Or, it is not
>>>worth reworking the patch.
>>
>>I think the amount of reworking outweighs the benefits of the patch.  But this
>>is my opinion, maybe you've seen real problem with tabs, so you might have a
>>better view of the benefits of detecting this.
> 
> 
> Well, my current patch (while not perfect) found 21 programs in 
> the testsuite that had illegal tab characters.  One program,
> 19990826-3.f, contained a leading tab in every line that wasn't
> a comment or labeled.

... which doesn't show that it was indeed a problem :-)

Implementation-wise I think we can warn for a \t in the first six characters
just below the place where you had put the warning (one would have to identify
comments, but this is easy enough in the first six columns, because
continuation lines and strings don't play a role there).  Then we can warn for
other tabs (which aren't expanded right away) later during the parsing.

WRT why I think this warning doesn't buy us much, enjoy my not well-researched
argument:  I don't see how the standard forbids tabs (outside strings).  If we
interpret tabs as 'as many blanks as needed to go to the next column which is
a multiple of 6 plus 1', I think we might well be within the domain of the
standard.

- Tobi


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