|Subject:||RE: [Bug-indent] No space before `*' in declarations|
|Date:||Sat, 7 Dec 2002 20:59:25 -0000|
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,
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.
|[Prev in Thread]||Current Thread||[Next in Thread]|