Thread: I can't compile cvs snapshot ...
The problem is with file conv.c in backend/utils/mb/
....
big52mic(unsigned char *big5, unsigned char *p, int len)
unsigned short c1; unsigned short big5buf, cnsBuf; unsigned char lc;
char bogusBuf[2]; int i;
while (len > 0 && (c1 = *big5++)){ if (c1 <= 0x007f U) ^^^^ my egcs 1.1.2
onlinux(rh6.0) doesn't accept this space. Should be
(probably) 0x007fU
......
The same problem repeats on some more places.
--
* David Sauer, student of Czech Technical University
* electronic mail: davids@orfinet.cz (mime compatible)
Thanks. I am working on it now.
> The problem is with file conv.c in backend/utils/mb/
> ....
> big52mic(unsigned char *big5, unsigned char *p, int len)
>
> unsigned short c1;
> unsigned short big5buf,
> cnsBuf;
> unsigned char lc;
> char bogusBuf[2];
> int i;
>
> while (len > 0 && (c1 = *big5++))
> {
> if (c1 <= 0x007f U)
> ^^^^ my egcs 1.1.2 on linux(rh6.0) doesn't
> accept this space. Should be
> (probably) 0x007fU
> ......
>
> The same problem repeats on some more places.
>
> --
> * David Sauer, student of Czech Technical University
> * electronic mail: davids@orfinet.cz (mime compatible)
>
>
-- 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
> The problem is with file conv.c in backend/utils/mb/
> ....
> big52mic(unsigned char *big5, unsigned char *p, int len)
>
> unsigned short c1;
> unsigned short big5buf,
> cnsBuf;
> unsigned char lc;
> char bogusBuf[2];
> int i;
>
> while (len > 0 && (c1 = *big5++))
> {
> if (c1 <= 0x007f U)
> ^^^^ my egcs 1.1.2 on linux(rh6.0) doesn't
> accept this space. Should be
> (probably) 0x007fU
> ......
>
> The same problem repeats on some more places.
OK, I have changed it to:
0x007f -> (unsigned)0x7f
This seems like the intent, and pgindent doesn't like the old format.
-- 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
> The problem is with file conv.c in backend/utils/mb/
> ....
> big52mic(unsigned char *big5, unsigned char *p, int len)
>
> unsigned short c1;
> unsigned short big5buf,
> cnsBuf;
> unsigned char lc;
> char bogusBuf[2];
> int i;
>
> while (len > 0 && (c1 = *big5++))
> {
> if (c1 <= 0x007f U)
> ^^^^ my egcs 1.1.2 on linux(rh6.0) doesn't
> accept this space. Should be
> (probably) 0x007fU
Before it was "0x007fU" and now is "0x007f U". Probably pgindent did
something.
>This seems like the intent, and pgindent doesn't like the old format.
Does this mean we are not allowed to use "U"? I think this is leagal
according to the standard C grammer.
---
Tatsuo Ishii
> Before it was "0x007fU" and now is "0x007f U". Probably pgindent did > something. > > >This seems like the intent, and pgindent doesn't like the old format. > > 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 you use it, pgindent will break it the next time I run it, and I will manually convert it to (unsigned). Is that OK? I can probably add some code to pgindent to work around the problem, as I have done for other indent issues if you would prefer. -- 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
>> 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 you use it, pgindent will break it the next time I run it, >and I will manually convert it to (unsigned). Is that OK? Ok. >I can probably add some code to pgindent to work around the problem, as >I have done for other indent issues if you would prefer. Well, it's a trivial problem, so I don't care about it. --- Tatsuo Ishii
> >> 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 you use it, pgindent will break it the next time I run it, > >and I will manually convert it to (unsigned). Is that OK? > > Ok. I hate for pgindent to be mucking with your multi-byte code. > >I can probably add some code to pgindent to work around the problem, as > >I have done for other indent issues if you would prefer. > > Well, it's a trivial problem, so I don't care about it. I was hoping you would say that. :-) -- 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
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.)
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?
regards, tom lane
> 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
> 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.) > > 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...) OK, here is the patch that is not in the tools/pgindent directory to understand 0x7fU constants. I will put the U's back in the constants. -- 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, Pennsylvania 19026 *** ./lexi.c.orig Wed May 26 10:50:54 1999 --- ./lexi.c Wed May 26 10:51:08 1999 *************** *** 186,192 **** *e_token++ = *buf_ptr++; } } ! if (*buf_ptr == 'L' || *buf_ptr == 'l') *e_token++ = *buf_ptr++; } else --- 186,193 ---- *e_token++ = *buf_ptr++; } } ! if (*buf_ptr == 'L' || *buf_ptr == 'U' || ! *buf_ptr == 'l' || *buf_ptr == 'u') *e_token++ = *buf_ptr++; } else