You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by Marvin Humphrey <ma...@rectangular.com> on 2010/01/14 17:31:16 UTC
Re: [KinoSearch] C90 vs C99
On Thu, Jan 14, 2010 at 09:27:48AM -0600, Peter Karman wrote:
> I seem to recall a recent move from C90 to C99 compliance (or was it the
> reverse?) as part of a Win32 compatibility change. (I could have the details
> wrong; memory is fuzzy.)
The new policy has never been explicity expressed. It is basically "the
intersection of C++ and C99". It can't quite be that because so few compilers
are 100% C99-compliant.
By compiling with MSVC in C++ mode, we are able to get the features of C99
that are most useful without dropping support for that compiler. One of these
is "mixed declarations and code". Another is "for loop initial declaration".
Before:
int i, max;
for (i = 0, max = thing->hello_count; i < max; i++) {
printf("Greetings, earthlings!\n");
}
After:
for (int i = 0, max = thing->hello_count; i < max; i++) {
printf("Greetings, earthlings!\n");
}
The latter is better because it scope-limits "i" and "max" to the loop where
they are needed.
> In any case, I've seen a couple instances lately of this kind of error:
>
> ../core/KinoSearch/Util/SortExternal.c: In function `S_find_endpost':
> ../core/KinoSearch/Util/SortExternal.c:194: error: 'for' loop initial
> declaration used outside C99 mode
> error building ../core/KinoSearch/Util/SortExternal.o from
> '../core/KinoSearch/Util/SortExternal.c'
A web search reveals that this is a GCC error, but it's unexpected because GCC
should be tolerant by default. Do the flags that you're passing to GCC
include "-std=c90", "-std=C89", or "-ansi"?
> I fixed one such issue in KS r5678
Heh, snuck that one by me.
Marvin Humphrey
Re: [KinoSearch] C90 vs C99
Posted by Peter Karman <pe...@peknet.com>.
Marvin Humphrey wrote on 1/14/10 12:09 PM:
>
> This stuff gets added in Build.pm. Take a look, you'll see the test for "cl",
> which is MSVC, and a similar check for GCC under the debugging flags.
>
Cool. Fix committed as r5688.
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [KinoSearch] C90 vs C99
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Thu, Jan 14, 2010 at 11:47:37AM -0600, Peter Karman wrote:
> yes, that makes the problem go away. The issue was present under gcc 3.4 (RHEL
> 4) and gcc 4.2 (OSX 10.6).
Ah. I'm not seeing it because I have 'export KINO_DEBUG=""' in my bash startup
code. And I just started using these idioms recently.
> Seems like making that flag explicit when gcc is detected would be a good thing.
> Does that kind of test properly go into Build.PL or into Charmonizer somewhere?
Charmonizer is never used to add compiler flags. It always runs with the set
of flags that you give it, since that's part of the compiler environment
it's supposed to suss out for you.
This stuff gets added in Build.pm. Take a look, you'll see the test for "cl",
which is MSVC, and a similar check for GCC under the debugging flags.
Marvin Humphrey
Re: C90 vs C99
Posted by Peter Karman <pe...@peknet.com>.
Marvin Humphrey wrote on 1/14/10 11:42 AM:
> On Thu, Jan 14, 2010 at 10:39:20AM -0600, Peter Karman wrote:
>>> A web search reveals that this is a GCC error, but it's unexpected because
>>> GCC should be tolerant by default. Do the flags that you're passing to GCC
>>> include "-std=c90", "-std=C89", or "-ansi"?
>> no.
>
> Hmm. Does adding "-std=c99" make the problem go away? Maybe GCC 3.x handled
> this differently.
>
yes, that makes the problem go away. The issue was present under gcc 3.4 (RHEL
4) and gcc 4.2 (OSX 10.6).
Seems like making that flag explicit when gcc is detected would be a good thing.
Does that kind of test properly go into Build.PL or into Charmonizer somewhere?
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: C90 vs C99
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Thu, Jan 14, 2010 at 10:39:20AM -0600, Peter Karman wrote:
>> A web search reveals that this is a GCC error, but it's unexpected because
>> GCC should be tolerant by default. Do the flags that you're passing to GCC
>> include "-std=c90", "-std=C89", or "-ansi"?
>
> no.
Hmm. Does adding "-std=c99" make the problem go away? Maybe GCC 3.x handled
this differently.
You can hack that flag into Build.pm quickly like so:
marvin@smokey:~/projects/ks/perl $ svn diff buildlib/
Index: buildlib/KinoSearch/Build.pm
===================================================================
--- buildlib/KinoSearch/Build.pm (revision 5679)
+++ buildlib/KinoSearch/Build.pm (working copy)
@@ -48,7 +48,7 @@
sub extra_ccflags {
my $self = shift;
- my $extra_ccflags = "";
+ my $extra_ccflags = "-std=c99 ";
if ( defined $ENV{KINO_DEBUG} ) {
$extra_ccflags .= "-DKINO_DEBUG ";
marvin@smokey:~/projects/ks/perl $
Alternatively, 'export KINO_DEBUG=""' in bash to get the GCC debugging flags,
which include "-std=c99".
Marvin Humphrey
Re: C90 vs C99
Posted by Peter Karman <pe...@peknet.com>.
Marvin Humphrey wrote on 1/14/10 10:31 AM:
> Before:
>
> int i, max;
> for (i = 0, max = thing->hello_count; i < max; i++) {
> printf("Greetings, earthlings!\n");
> }
>
> After:
>
> for (int i = 0, max = thing->hello_count; i < max; i++) {
> printf("Greetings, earthlings!\n");
> }
>
> The latter is better because it scope-limits "i" and "max" to the loop where
> they are needed.
>
yes, I can see why it's better. As long as it compiles, that is. ;)
> A web search reveals that this is a GCC error, but it's unexpected because GCC
> should be tolerant by default. Do the flags that you're passing to GCC
> include "-std=c90", "-std=C89", or "-ansi"?
>
>
no.
cc -I. -I../core -Iautogen -Ixs -I../charmonizer/gen
-I/opt/pij/lib/perl5/5.8.9/x86_64-linux/CORE -fPIC -c -fno-strict-aliasing -pipe
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/include/gdbm -O2 -o ../core/KinoSearch/Util/SortExternal.o
../core/KinoSearch/Util/SortExternal.c
../core/KinoSearch/Util/SortExternal.c: In function `S_find_endpost':
../core/KinoSearch/Util/SortExternal.c:194: error: 'for' loop initial
declaration used outside C99 mode
error building ../core/KinoSearch/Util/SortExternal.o from
'../core/KinoSearch/Util/SortExternal.c' at
/opt/pij/lib/perl5/site_perl/5.8.9/ExtUtils/CBuilder/Base.pm line 112.
make: *** [test] Error 2
[pijuser@pijnatdev perl]$ cc -v
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)
--
Peter Karman . http://peknet.com/ . peter@peknet.com