pgsql: Document struct/union problem with pgindent.

Started by Nonameover 16 years ago6 messages
#1Noname
momjian@postgresql.org

Log Message:
-----------
Document struct/union problem with pgindent.

Modified Files:
--------------
pgsql/src/tools/pgindent:
pgindent (r1.100 -> r1.101)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/tools/pgindent/pgindent?r1=1.100&r2=1.101)

#2Andrew Dunstan
andrew@dunslane.net
In reply to: Noname (#1)
Re: [COMMITTERS] pgsql: Document struct/union problem with pgindent.

Bruce Momjian wrote:

+ #
+ # Structure/union pointers in function prototypes and definitions have an extra
+ # space after the asterisk:
+ #
+ #	void x(struct xxc * a);

I know we should not be driven by our tools, but is there a case for a
coding standard that requires use of a typedef name here?

cheers

andrew

#3Alvaro Herrera
alvherre@commandprompt.com
In reply to: Andrew Dunstan (#2)
Re: [COMMITTERS] pgsql: Document struct/union problem with pgindent.

Andrew Dunstan wrote:

Bruce Momjian wrote:

+ #
+ # Structure/union pointers in function prototypes and definitions have an extra
+ # space after the asterisk:
+ #
+ #	void x(struct xxc * a);

I know we should not be driven by our tools, but is there a case for a
coding standard that requires use of a typedef name here?

We use things like struct timeval and struct tm ... I don't think we
should be creating typedefs for those, so it would be good to find a
more general solution.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andrew Dunstan (#2)
Re: [COMMITTERS] pgsql: Document struct/union problem with pgindent.

Andrew Dunstan <andrew@dunslane.net> writes:

Bruce Momjian wrote:
+ # Structure/union pointers in function prototypes and definitions have an extra
+ # space after the asterisk:
+ #
+ #	void x(struct xxc * a);

I know we should not be driven by our tools, but is there a case for a
coding standard that requires use of a typedef name here?

I don't think so. Shall we artificially create a typedef for standard
objects like "struct stat" in order to follow such a coding rule? I
think that's just a recipe for confusion.

In any case, a big fraction of the places that have this issue are code
that we've imported from elsewhere (the regex engine, zic) and changing
to typedefs would mean even more drift from upstream and hence
difficulty in following their patches.

It's just a bug in pgindent that we should try to fix sometime.

regards, tom lane

#5Andrew Dunstan
andrew@dunslane.net
In reply to: Alvaro Herrera (#3)
Re: [COMMITTERS] pgsql: Document struct/union problem with pgindent.

Alvaro Herrera wrote:

Andrew Dunstan wrote:

Bruce Momjian wrote:

+ #
+ # Structure/union pointers in function prototypes and definitions have an extra
+ # space after the asterisk:
+ #
+ #	void x(struct xxc * a);

I know we should not be driven by our tools, but is there a case for a
coding standard that requires use of a typedef name here?

We use things like struct timeval and struct tm ... I don't think we
should be creating typedefs for those, so it would be good to find a
more general solution.

Good point.

cheers

andrew

#6Bruce Momjian
bruce@momjian.us
In reply to: Tom Lane (#4)
Re: [COMMITTERS] pgsql: Document struct/union problem with pgindent.

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Bruce Momjian wrote:
+ # Structure/union pointers in function prototypes and definitions have an extra
+ # space after the asterisk:
+ #
+ #	void x(struct xxc * a);

I know we should not be driven by our tools, but is there a case for a
coding standard that requires use of a typedef name here?

I don't think so. Shall we artificially create a typedef for standard
objects like "struct stat" in order to follow such a coding rule? I
think that's just a recipe for confusion.

In any case, a big fraction of the places that have this issue are code
that we've imported from elsewhere (the regex engine, zic) and changing
to typedefs would mean even more drift from upstream and hence
difficulty in following their patches.

It's just a bug in pgindent that we should try to fix sometime.

I would hope switching to GNU indent would fix this, but might bring new
bugs.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +