|
From: | David Ingamells |
Subject: | RE: [Bug-indent] No space before `*' in declarations |
Date: | Sat, 7 Dec 2002 20:59:25 -0000 |
Pavel, I agree that all types should be treated equally and consistently, but
I'm afraid that you're asking indent for more than it is currently capable of,
even with some bug fixes. This is the very reason that a rewrite of indent has
been on the GNU project proposal list (and now a start is being made to do just
that). In order for the lexical analyser to know what a name is it must, one
way or another, be told what it is. In the current indent that is via the -T
argument. In a parser that fully understands the C rules _and_ the pre-processor
rules it is possible to have the parser add the name to the name table that lex uses when a typedef is
encountered. However that also is not without its drawbacks: the parser must be
given the same list of include paths that the compiler is given and must also
be run in the same environment, so that the same include files are found. Where
complex make files are used that would probably require that indent be driven
by the same makefile. You might also have noticed that emacs' C
mode has the same problem with its syntax colouring scheme: it is a tricky
problem that does not have an easy answer. The job of the lexical analyser is to break up the input into tokens
(e.g. '*') and it is the job of the parser to decide, based upon the context,
what each token means (binary operator, pointer declarator
or de-referencer operator). Therefore it is wrong of
a lexical stage to apply _any_ meaning to '*'. Unfortunately indent muddles all
the stages (lexical, parse and output) into each other and it need a good
clean-up, which is slowly happening. Finally, my remark about the flurry of complaints is because others (me
included) will disagree with your statement "There should not be any space
after '*' in function declarations." The following is a common style: int
* func( char
* string, int number); I do agree that the user should be given the choice and ideally that
choice should be applied consistently, however unfortunately it will be some
while before indent or its replacement will be capable of doing that without
using the -T argument. I will have a look at your proposed patch when the chance
arises - it may generally be a better solution than the current indent. David. |
[Prev in Thread] | Current Thread | [Next in Thread] |