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
