Re: Re: [PATCHES] s_lock.h cleanup
От | Bruce Momjian |
---|---|
Тема | Re: Re: [PATCHES] s_lock.h cleanup |
Дата | |
Msg-id | 200101191839.NAA03380@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Re: [PATCHES] s_lock.h cleanup (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> Peter Eisentraut <peter_e@gmx.net> writes: > > Bruce Momjian writes: > >> In looking at the VAX ASM problem, I realized that the ASM in s_lock.h > >> is all formatted differently, making it even more confusing. I have > >> applied the following patch to s_lock.h to try and clean it up. > > > I don't believe in this patch at all. It makes the assumption that all > > assemblers have equally forgiving lexical rules as a certain subset of > > said assemblers. For example, the VAX code does not look at all like the > > one back when it still worked. > > Good point. I think it's safe to use the split-up-string-literal > feature, but assuming that ';' can replace '\n' is sheer folly, and so > is assuming that whitespace doesn't matter (ie, that opcodes starting > in column 1 are OK). Bruce, I'd suggest a format more like > > "[label] opcode operands \n" > > for each line of assembly code. Interestingly, we have very few non-gcc ASM entries in s_lock.h. The only non-gcc one I see are Univel/i386, and I didn't touch that. Isn't the semicolon the standard command terminator for all gcc assemblers? I see non-gcc stuff in s_lock.c, but I didn't touch that. I also see volatile missing in s_lock.c, which I will add for GCC entries. -- Bruce Momjian | http://candle.pha.pa.us pgman@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 по дате отправления: