Re: src/tools/pginclude considered harmful (was Re:
От | Bruce Momjian |
---|---|
Тема | Re: src/tools/pginclude considered harmful (was Re: |
Дата | |
Msg-id | 200607142202.k6EM2wx15670@momjian.us обсуждение исходный текст |
Ответы |
Re: src/tools/pginclude considered harmful (was Re: [PATCHES]
|
Список | pgsql-hackers |
Tom Lane wrote: > Martijn van Oosterhout <kleptog@svana.org> writes: > > On Fri, Jul 14, 2006 at 04:24:59PM -0400, Tom Lane wrote: > >> After some reflection it seems that there is only one case where removal > >> of a needed include file would not lead to a compiler error or warning, > >> assuming gcc with ordinary -W settings (notably -Wmissing-prototypes). > >> That case is exactly what Kris found: removal of a #define that is > >> tested via #ifdef or #if defined(). (Can anyone think of other cases?) > > > My off-the-top-of-my-head solution would be a script that would pass > > each file through "gcc -E" (the preprocessor), and compare before and > > after rearrangement. You'd have to ignore the effects of included > > header files, but it would pick up the cases where a block of code that > > was previously included no longer is. Or if a macro is expanded > > differently... > > You'd still have to try to compile the code though; AFAICS the above > doesn't catch whether you've removed a typedef or function declaration > that's referenced in the file. > > BTW, one of the remaining holes in pgrminclude is that it compiles with > -fsyntax-only, which apparently causes it to fail to detect some errors > of significance --- I assume that's how it managed to foul up lmgr.c, > inet_net_ntop.c, etc. But I do run a full compile and regression before commit, so that should have caught it even if pgrminclude didn't. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: