Re: pgsql: Fix thinko in previous commit
От | Tom Lane |
---|---|
Тема | Re: pgsql: Fix thinko in previous commit |
Дата | |
Msg-id | 20695.1349757261@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: Fix thinko in previous commit (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: pgsql: Fix thinko in previous commit
|
Список | pgsql-committers |
Alvaro Herrera <alvherre@2ndquadrant.com> writes: > (It seems to me that spoonbill is disabling USE_INLINE because of new > warnings that are probably caused by the FORTIFY_SOURCE stuff. This > seems to be interacting strangely with the new uses of USE_INLINE in the > headers I modified.) No, those aren't from _FORTIFY_SOURCE; that macro doesn't cause warnings like this, and even if it did, we're not setting it on spoonbill because that isn't a Linux machine. Spoonbill's toolchain seems to be afflicted with a case of terminal stupidity (I'd use a more colorful word but I'm trying to be polite): configure:15121: checking for quiet inline (no complaint if unreferenced) configure:15151: gcc -o conftest -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -g -I/usr/local/include/libxml2-I/usr/local/include -I/usr/local/include -I/usr/local/include/libxml2 -I/usr/include/kerberosV-L/usr/local/lib/ -lpthread -lcrypto -liconv -L/usr/local/lib -L/usr/local/lib -L/usr/local/libconftest.c -lxslt -lxml2 -lssl -lcrypto -lkrb5 -lz -ledit -ltermcap -lm >&5 /usr/local/lib//libxml2.so.12.0: warning: strcpy() is almost always misused, please use strlcpy() /usr/local/lib//libxml2.so.12.0: warning: strcat() is almost always misused, please use strlcat() /usr/local/lib//libxslt.so.3.8: warning: sprintf() is often misused, please use snprintf() Note that these warnings are not due to anything in the source code being compiled; they appear to be looking at references in the libraries it's including. Whoever thought that would be useful deserves nothing but contempt, even if you grant that his bias against any use whatsoever of these functions is legitimate (which I don't). But having said that, it seems there's something wrong with the STATIC_IF_INLINE patch for the case where USE_INLINE doesn't get set. I'm too tired to investigate right now, but if you manually disable USE_INLINE in pg_config.h after configuring, do you see a problem? regards, tom lane
В списке pgsql-committers по дате отправления: