Обсуждение: Fw: Case Insensitive Test
----- Original Message ----- From: "Manuel Sugawara" <masm@fciencias.unam.mx> To: "Donald Fraser" <demolish@cwgsy.net> Cc: "[ADMIN]" <pgsql-admin@postgresql.org> Sent: Thursday, September 25, 2003 11:12 PM Subject: Re: [ADMIN] Case Insensitive Test > "Donald Fraser" <demolish@cwgsy.net> writes: > > > The Case Insensitive Text data type for PostgreSQL is now part of > > the GBorg projects. > > > > http://gborg.postgresql.org/project/citext/projdisplay.php > > Nice work, just two comments (1) the C++ comment style (//) is not > portable for C programs and should be changed and (2) the standard way Fair comment but since it has to be compiled against a valid PosgtreSQL distribution, which all require GNU compilers, I don't see what the problem is. All the C GNU compilers that I've ever used support C++ style comments which in my opinion are much nicer to use. > to distribute this kind of stuff is a tarball, zip is more from the > windows world. Ok its I added the tar.gz file to the distribution, which you'll note it twice the size of the zip file. May be I don't know how to use tar properly but that's why I used the zip format - it always seems to come out smaller by at least a factor of 2. Regards Donald
"Donald Fraser" <demolish@cwgsy.net> writes:
>> Nice work, just two comments (1) the C++ comment style (//) is not
>> portable for C programs and should be changed and (2) the standard way
> Fair comment but since it has to be compiled against a valid PosgtreSQL
> distribution, which all require GNU compilers,
We have several beta testers who keep us honest on exactly this point;
they use compilers that do not take //. Personally I wish gcc could
be configured not to have these little non-ANSI-isms ...
> Ok its I added the tar.gz file to the distribution, which you'll note
> it twice the size of the zip file.
Shouldn't be. Did you use "gzip -9"? For instance, I get these sorts
of numbers on a directory full of C source files:
$ ls -l z.*
-rw-r--r-- 1 tgl users 142048 Sep 25 20:40 z.tar.gz
-rw-r--r-- 1 tgl users 156389 Sep 25 20:41 z.zip
regards, tom lane
--On Thursday, September 25, 2003 20:43:36 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Donald Fraser" <demolish@cwgsy.net> writes: >>> Nice work, just two comments (1) the C++ comment style (//) is not >>> portable for C programs and should be changed and (2) the standard way > >> Fair comment but since it has to be compiled against a valid PosgtreSQL >> distribution, which all require GNU compilers, > > We have several beta testers who keep us honest on exactly this point; > they use compilers that do not take //. Personally I wish gcc could > be configured not to have these little non-ANSI-isms ... Actually, I *THINK* C99 allows // comments, but that's neither here nor there. Any pre-C99 Non-GCC compiler won't allow it (I'm one of the aforementioned beta testers, I use the SCO cc (native) compiler on UnixWare)). -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Вложения
Larry Rosenman <ler@lerctr.org> writes:
>> We have several beta testers who keep us honest on exactly this point;
>> they use compilers that do not take //. Personally I wish gcc could
>> be configured not to have these little non-ANSI-isms ...
> Actually, I *THINK* C99 allows // comments, but that's neither here nor
> there.
It does, but we still try to conform to ANSI C (C89 or whenever it was).
regards, tom lane
"Chad R. Larson" <chad@eldocomp.com> writes:
> I suspect that among the conformance switches, you can find a combination
> you like:
I've been through them. None of 'em turn off // comments. Or #-sign
preprocessor assertions, or a few other post-ANSI-C inventions.
(Hell, preprocessor assertions aren't in C99 either.)
> Also, look at the warning options "-pedantic" and "-pedantic-errors".
As the GCC folks advise, those are useful only for pedants. I'm not
interested in pedantry, but portability. I don't think the GCC guys
really care about backwards compatibility to old compilers ... which
is surely their right, but it's kind of a problem for those of us
who'd like to maintain portable application code.
regards, tom lane
On Fri, 26 Sep 2003, Tom Lane wrote:
> "Chad R. Larson" <chad@eldocomp.com> writes:
> > I suspect that among the conformance switches, you can find a combination
> > you like:
>
> I've been through them. None of 'em turn off // comments. Or #-sign
On at least some versions of gcc it looks like --std=c89 turns them off
(my system's 3.2 does and so does another's 2.95.4)
I used the little program:
#include <stdio.h>
int main() {
int a1 = 5 //*2*/
+3;
printf("%d\n", a1);
}
Without the option, 8 is printed, with it 1 is printed.
We don't appear to compile with the option on my system however. It looks
like differences between the includes in test programs in configure and
when actually building cause errors. In my case struct addrinfo isn't
found in configure, but it is found when actually building (due indirectly
to an include of stdio.h) causing redefinition errors.
Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
>> I've been through them. None of 'em turn off // comments. Or #-sign
> On at least some versions of gcc it looks like --std=c89 turns them off
Hmm, I haven't tried that in particular. I wonder what else it does?
> We don't appear to compile with the option on my system however.
Yeah, I was just fighting what seemed to be a similar problem on Mac
OS X. The vendors may or may not check that their compiler handles
all 2^N combinations of switches ... but for sure they don't check
that all the header files they supply will compile under all 2^N
combinations of switches ...
regards, tom lane
At 06:24 PM 9/25/2003 , Tom Lane wrote:
>Larry Rosenman <ler@lerctr.org> writes:
> >> We have several beta testers who keep us honest on exactly this point;
> >> they use compilers that do not take //. Personally I wish gcc could
> >> be configured not to have these little non-ANSI-isms ...
I suspect that among the conformance switches, you can find a combination
you like:
----------------------------------
Language Options
-ansi -fall-virtual -fcond-mismatch -fdollars-in-identifiers
-fenum-int-equiv -fexternal-templates -fno-asm -fno-builtin
-fhosted -fno-hosted -ffreestanding -fno-freestanding
-fno-strict-prototype -fsigned-bitfields -fsigned-char
-fthis-is-variable -funsigned-bitfields -funsigned-char
-fwritable-strings -traditional -traditional-cpp -trigraphs
---------------------------------
Also, look at the warning options "-pedantic" and "-pedantic-errors".
-- CONFIDENTIALITY NOTICE --
This message is intended for the sole use of the individual and entity to whom it is addressed, and may contain
informationthat is privileged, confidential and exempt from disclosure under applicable law. If you are not the
intendedaddressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use,
copy,disclose or distribute to anyone the message or any information contained in the message. If you have received
thismessage in error, please immediately advise the sender by reply email, and delete the message. Thank you.
On Thu, 25 Sep 2003, Tom Lane wrote: > "Donald Fraser" <demolish@cwgsy.net> writes: > >> Nice work, just two comments (1) the C++ comment style (//) is not > >> portable for C programs and should be changed and (2) the standard way > > > Fair comment but since it has to be compiled against a valid PosgtreSQL > > distribution, which all require GNU compilers, > > We have several beta testers who keep us honest on exactly this point; > they use compilers that do not take //. Personally I wish gcc could > be configured not to have these little non-ANSI-isms ... > > > Ok its I added the tar.gz file to the distribution, which you'll note > > it twice the size of the zip file. > > Shouldn't be. Did you use "gzip -9"? For instance, I get these sorts > of numbers on a directory full of C source files: > > $ ls -l z.* > -rw-r--r-- 1 tgl users 142048 Sep 25 20:40 z.tar.gz > -rw-r--r-- 1 tgl users 156389 Sep 25 20:41 z.zip And, as always, bzip2 beats them both: ls -l cit* -rw------- 1 scott.ma scott.ma 6317 Sep 26 08:06 citext.tar.bz2 -rw------- 1 scott.ma scott.ma 7056 Sep 26 08:00 citext.tar.gz -rw------- 1 scott.ma scott.ma 7334 Sep 26 08:01 citext.zip (gzip run with -9 switch)
On Fri, 26 Sep 2003, Tom Lane wrote: > Stephan Szabo <sszabo@megazone.bigpanda.com> writes: > >> I've been through them. None of 'em turn off // comments. Or #-sign > > > On at least some versions of gcc it looks like --std=c89 turns them off > > Hmm, I haven't tried that in particular. I wonder what else it does? It looks from the headers, that by default that'll not define a bunch of extensions stuff. It's apparently enough stuff that even if I get around the immediate problem I had I get a complaint about SIG_SETMASK being undeclared (it looks like it's only defined when __USE_POSIX). However, the immediate problem I have seems to come from the fact that on Linux at least we're basically lying to configure about what's in the system headers when we go to compile. port/linux.h on my system defined _GNU_SOURCE which forces most/all of the extension things to be defined even if they wouldn't by the command line options. So, the compilation sees different contents of the headers than configure did which means that configure may say that something isn't defined, but it might be when we go and compile.
Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> However, the immediate problem I have seems to come from the fact that
> on Linux at least we're basically lying to configure about what's in the
> system headers when we go to compile. port/linux.h on my system defined
> _GNU_SOURCE which forces most/all of the extension things to be defined
> even if they wouldn't by the command line options.
Hm. I have to plead guilty to putting that #define in there. It was a
quick-and-dirty workaround to make plperl compile. Perhaps a better
solution would be for template/linux to add the appropriate thing to
CPPFLAGS, so that configure would see the same environment. Can you
try that and see if it fixes your issue? (What exactly is your issue,
anyway?)
regards, tom lane
On Fri, 26 Sep 2003, Tom Lane wrote: > Stephan Szabo <sszabo@megazone.bigpanda.com> writes: > > However, the immediate problem I have seems to come from the fact that > > on Linux at least we're basically lying to configure about what's in the > > system headers when we go to compile. port/linux.h on my system defined > > _GNU_SOURCE which forces most/all of the extension things to be defined > > even if they wouldn't by the command line options. > > Hm. I have to plead guilty to putting that #define in there. It was a > quick-and-dirty workaround to make plperl compile. Perhaps a better > solution would be for template/linux to add the appropriate thing to > CPPFLAGS, so that configure would see the same environment. Can you > try that and see if it fixes your issue? (What exactly is your issue, > anyway?) Configure doesn't find struct addrinfo (because it's in a __USE_POSIX block) so it looks like we use our own version, but, when we're actually then compiling getaddrinfo.c, there's a redefinition error because this time struct addrinfo is found (because _GNU_SOURCE forces __USE_POSIX). It looks like commenting it out of linux.h and adding it to template/linux works for the main build, it compiles and links fine both with and without --std=c89 and the latter also passes regression. I didn't try to build plperl however.
Вложения
Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> It looks like commenting it out of linux.h and adding it to template/linux
> works for the main build, it compiles and links fine both with and without
> --std=c89 and the latter also passes regression. I didn't try to build
> plperl however.
Okay, I verified that it still works for plperl (and that I do still see
the plperl failure without _GNU_SOURCE). Patch committed.
regards, tom lane
Tom Lane wrote: > Stephan Szabo <sszabo@megazone.bigpanda.com> writes: > > It looks like commenting it out of linux.h and adding it to template/linux > > works for the main build, it compiles and links fine both with and without > > --std=c89 and the latter also passes regression. I didn't try to build > > plperl however. > > Okay, I verified that it still works for plperl (and that I do still see > the plperl failure without _GNU_SOURCE). Patch committed. That _GNU_SOURCE has always bothered me. What does it control, exactly? It seems to control a lot. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> That _GNU_SOURCE has always bothered me. What does it control, exactly?
> It seems to control a lot.
Well, without it I get (on RHL 8.0)
gcc -O2 -g -fpic -I. -I/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE -I../../../src/include -c -o plperl.o
plperl.c
In file included from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/op.h:480,
from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/perl.h:2209,
from plperl.c:60:
/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/reentr.h:602: field `_crypt_struct' has incomplete type
/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/reentr.h:747: confused by earlier errors, bailing out
make: *** [plperl.o] Error 1
The relevant chunk of that Perl header is
#ifdef HAS_CRYPT_R
#if CRYPT_R_PROTO == REENTRANT_PROTO_B_CCD
CRYPTD* _crypt_data;
#else
struct crypt_data _crypt_struct;
#endif
#endif /* HAS_CRYPT_R */
and the problem is that HAS_CRYPT_R has gotten defined but "struct
crypt_data" has not. It's been awhile since I looked at this, but I
think that Perl configures HAS_CRYPT_R on the basis of a link-only test
for crypt_r(), which will succeed regardless of -D symbols. And (in
this Linux version, anyway) /usr/include/crypt.h only defines struct
crypt_data if __USE_GNU is defined (which comes from _GNU_SOURCE).
So we're more or less stuck --- perl.h simply does not compile without
_GNU_SOURCE on this platform.
This is arguably a configuration bug in Perl; we have hit comparable
difficulties in PG, and had to solve them by the expedient of testing
for both compile-time and link-time presence of library features.
They're not being careful enough.
Experimenting, I notice that ecpg also currently fails to compile
without _GNU_SOURCE on that box. It looks to me like the system headers
have a rather arbitrary set of ideas on what to remove when _GNU_SOURCE
isn't defined...
regards, tom lane
Tom Lane wrote: > and the problem is that HAS_CRYPT_R has gotten defined but "struct > crypt_data" has not. It's been awhile since I looked at this, but I > think that Perl configures HAS_CRYPT_R on the basis of a link-only test > for crypt_r(), which will succeed regardless of -D symbols. And (in > this Linux version, anyway) /usr/include/crypt.h only defines struct > crypt_data if __USE_GNU is defined (which comes from _GNU_SOURCE). > So we're more or less stuck --- perl.h simply does not compile without > _GNU_SOURCE on this platform. > > This is arguably a configuration bug in Perl; we have hit comparable > difficulties in PG, and had to solve them by the expedient of testing > for both compile-time and link-time presence of library features. > They're not being careful enough. > > Experimenting, I notice that ecpg also currently fails to compile > without _GNU_SOURCE on that box. It looks to me like the system headers > have a rather arbitrary set of ideas on what to remove when _GNU_SOURCE > isn't defined... I know the Pg:DBD guys had to define _GNU_SOURCE to get something working, but it wasn't per-platform, and I was concerned about that. They found another way to do it and have to test to see if it is going to work for all configuration. I just don't know if _GNU_SOURCE opens up other problems that we will only find later --- it seems like a large knob, but if it is required, it is required, I guess. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Stephan Szabo writes: > Configure doesn't find struct addrinfo (because it's in a __USE_POSIX > block) so it looks like we use our own version, but, when we're actually > then compiling getaddrinfo.c, there's a redefinition error because this > time struct addrinfo is found (because _GNU_SOURCE forces __USE_POSIX). What exact system is this on? I've compiled PG on a number of Linux systems since struct addrinfo started to appear, and I've never had a problem. Neither have others. -- Peter Eisentraut peter_e@gmx.net
On Fri, 26 Sep 2003, Peter Eisentraut wrote: > Stephan Szabo writes: > > > Configure doesn't find struct addrinfo (because it's in a __USE_POSIX > > block) so it looks like we use our own version, but, when we're actually > > then compiling getaddrinfo.c, there's a redefinition error because this > > time struct addrinfo is found (because _GNU_SOURCE forces __USE_POSIX). > > What exact system is this on? I've compiled PG on a number of Linux > systems since struct addrinfo started to appear, and I've never had a > problem. Neither have others. It's not a problem for me unless I'm compiling with CFLAGS="-std=c89".
Stephan Szabo writes: > It's not a problem for me unless I'm compiling with CFLAGS="-std=c89". Don't do that then. :-) I don't agree with cluttering the compile line with -D_GNU_SOURCE just for the case when someone adds additional unsupported compiler flags. We might as well add -fhosted just in case someone tries to compile with -ffreestanding. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> I don't agree with cluttering the compile line with -D_GNU_SOURCE just for
> the case when someone adds additional unsupported compiler flags.
Like "--with-perl"? The reason that got in there was not to deal with
weird compiler flags, it was to deal with the standard Perl installation
on RHL 8.0.
regards, tom lane
On Fri, 26 Sep 2003, Peter Eisentraut wrote: > Stephan Szabo writes: > > > It's not a problem for me unless I'm compiling with CFLAGS="-std=c89". > > Don't do that then. :-) Well, the discussion started with Tom trying to find an option that disallowed // comments for gcc. :) > I don't agree with cluttering the compile line with -D_GNU_SOURCE just for > the case when someone adds additional unsupported compiler flags. We > might as well add -fhosted just in case someone tries to compile with > -ffreestanding. Fundamentally however, having configure run with a fundamentally different compilation environment from an actual build (which _GNU_SOURCE basically does) is dangerous. Even without -std=c89, can we say for sure that the environment without it is exactly the same as with it?
Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> Fundamentally however, having configure run with a fundamentally different
> compilation environment from an actual build (which _GNU_SOURCE basically
> does) is dangerous.
Yes, having put _GNU_SOURCE into the port header rather than the port
template file is an obvious error in hindsight. Mea culpa on that one.
regards, tom lane
Tom Lane writes: > Peter Eisentraut <peter_e@gmx.net> writes: > > I don't agree with cluttering the compile line with -D_GNU_SOURCE just for > > the case when someone adds additional unsupported compiler flags. > > Like "--with-perl"? The reason that got in there was not to deal with > weird compiler flags, it was to deal with the standard Perl installation > on RHL 8.0. But for that purpose it was sufficient to leave it in linux.h. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> Like "--with-perl"? The reason that got in there was not to deal with
>> weird compiler flags, it was to deal with the standard Perl installation
>> on RHL 8.0.
> But for that purpose it was sufficient to leave it in linux.h.
But Stephan is right: putting it in the port header creates a serious
risk that the effective compilation environment will be different from
what configure was probing. It's sheer luck that we've not seen any
worse problems than we have.
regards, tom lane