Re: [HACKERS] I can't compile cvs snapshot ... - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] I can't compile cvs snapshot ...
Date
Msg-id 199905261400.KAA23943@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] I can't compile cvs snapshot ...  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> >> Does this mean we are not allowed to use "U"? I think this is leagal
> >> according to the standard C grammer.
> 
> > Well, it seems BSD indent mucks up 0x7fU, so I would prefer if we didn't
> > use it.
> 
> If pgindent mucks up standard C constructs then pgindent is broken.
> 
> This is not open to debate --- if you are going to run our entire
> source base through pgindent just a few days before every release,
> then the tool has to be something we can have 100 percent, no-questions-
> asked confidence in.  Telling people to obey weird little coding
> conventions is no answer.  (If everyone reliably did that, we'd not
> need pgindent in the first place.)
> 

pgindent gives us so many advanates, why worry about a small thing like
0xffU.  I will add to the patch I supply in the pgindent directory to
handle U also.

> It appears that BSD indent doesn't have a problem with 0xnnnL, so
> teaching it about 0xnnnU can't be that hard if you have the source.
> (I don't...)
> 
> Maybe it is time to take another look at GNU indent?

You don't want to go there.  See the tools/pgindent directory for an
explaination.  GNU indent has many bugs that wack the code silly.  Try
running any directory with GNU indent and compare it to the pgindent
version.


--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] I can't compile cvs snapshot ...
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Memory leak in large objects (was Re: Postgreqsl Large Objects)