From juan.guerrero at gmx.de Fri Feb 1 04:01:17 2008 From: juan.guerrero at gmx.de (Juan Manuel Guerrero) Date: Fri, 1 Feb 2008 13:01:17 +0100 Subject: [splint-discuss] Syntax of INCLUDE and LARCH_PATH environment variables Message-ID: <200802011301.17455.juan.guerrero@gmx.de> A couple of weeks ago while I was porting Splint 3.1.2 to MSDOS and clones using the DJGPP compiling environment I have observed the following issue that is OS and compiling environment independent and that I do not understand. The issue is the different behaviour if splint is started with the "-I" command line option or used with the INCLUDE environment variable instead. E.G.: if the INCLUDE environment variable is not set and splint is started with a command like this: splint -I /include foo.c then an entry in the g_cppState struct will be created for the chain of include dirs to be searched for. If the user decides to set the INCLUDE environment variable with this value and omit the "-I /include" option from the command line no entry at all is produced for g_cppState struct and the header files may not be found. The situation changes if the user terminates the string with the path separating char for that OS. E.G.: this works as expected: INCLUDE=/include: Please note the colon at the end of the environment value. It is the path separating char for posix OSs. The reason for this behaviour becomes clear when the following code snippet form function main() in llmain.c is inspected: [snip] cstring incval = cstring_copy (osd_getEnvironmentVariable (INCLUDEPATH_VAR)); cstring oincval = incval; if (cstring_isDefined (incval)) { /* ** Each directory on the include path is a system include directory. */ DPRINTF (("include: %s", incval)); context_setString (FLG_SYSTEMDIRS, cstring_copy (incval)); while (cstring_isDefined (incval)) { /*@access cstring@*/ char *nextsep = strchr (incval, PATH_SEPARATOR); if (nextsep != NULL) { cstring dir; *nextsep = '\0'; dir = cstring_copy (incval); if (cstring_length (dir) == 0 || !isalpha ((int) cstring_firstChar (dir))) { /* ** win32 environment values can have special values, ** ignore them */ } else { cppAddIncludeDir (dir); } *nextsep = PATH_SEPARATOR; incval = cstring_fromChars (nextsep + 1); cstring_free (dir); } else { break; } /*@noaccess cstring@*/ } } [snip] The variable incval contains the value of the INCLUDE environment variable. As can be seen the code line: char *nextsep = strchr (incval, PATH_SEPARATOR); checks for the occurence of the path separating char. If there is no one then the value of INCLUDE is simply completely ignored. This means that the user must always remember to add a last colon to the environment variable. This is realy quite unusual. It is important to notice that if there are multiple entries in the INCLUDE variable like this: INCLUDE=/include1:/include2:/include3 the last entry (/include3 in this case) is always ignored because it is has not been terminated with a path separating char. It is instructive to notice that the same behaviour happens for the LARCH_PATH environment variable. Now the question arises if this is a bug or a feature? I have inspected the splint documentation and it was not possible to me to find a clear description of the syntax of the INCLUDE and LARCH_PATH environment variables. IMHO or the parsing code for the variables must be a changed or the documentation must clearly explain what the syntax of the environment variables shall look like. If I am missing something, please let me know. Regards, Juan M. Guerrero From jakykong at theanythingbox.com Tue Feb 26 15:19:00 2008 From: jakykong at theanythingbox.com (Jack T Mudge III) Date: Tue, 26 Feb 2008 15:19:00 -0800 Subject: [splint-discuss] glib header and empty #define's Message-ID: <200802261519.06546.jakykong@theanythingbox.com> Greetings! This is my first message on this list. I've never used splint before (although I just finished perusing the manual somewhat, and the program appears enticing enough to be worth some work). I'm developing a small program to help me organize my homework a bit, and thought I'd give splint a try with it. Created some source code that compiles and runs flawlessly, but can't get past the glib header file (parse error). I realize one option is to skip the header file alltogether, but splint complains about unknown identifiers, and dies when I try to treat an int (which was defined as a GString, but defaulted to int when splint didn't know what a GString was, apparently) as a struct, and try to dereference it. I did some hunting, and I'm pretty sure I narrowed the problem down to this: in /usr/include/glib-2.0/glib/gmacros.h /* Guard C code in headers, while including them from C++ */ #ifdef __cplusplus # define G_BEGIN_DECLS extern "C" { # define G_END_DECLS } #else # define G_BEGIN_DECLS ; # define G_END_DECLS ; #endif This file is included by every other header in the glib library, in this case specifically in /usr/include/glib-2.0/glib/gtypes.h (which I included in my source file). The point of this snippet seems to be to keep some declarations from causing problems for C++ compilers, which is fine. I generally don't use C++, so I'm not as familiar with some of these idioms. The definition G_BEGIN_DECLS and G_END_DECLS, then, should be "" in my source file -- __cplusplus is NOT defined. However, splint feeds me this error instead of skipping over it (since a blank definition does nothing): /usr/include/glib/gtypes.h:41:8: Parse Error: Non-function declaration: G_BEGIN_DECLS : int. (For help on parse errors, see splint -help parseerrors.) I have tried adding #define G_BEGIN_DECLS ; to my source file, and splint complains about a duplicate definition (so apparently it's getting to the definition in the first place). Unfortunately, I'm out of ideas except for removing this code from my header files (since I'm not using C++, it shouldn't do any harm to do that, but it seems drastic to me). Does anyone have some ideas as to how to get splint past these defines? -- Sincerely, Jack Mudge jakykong at theanythingbox.com My GPG Public Key can be found at: https://www.theanythingbox.com/pgp.htm and Below. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20080226/e597883d/attachment.bin From Michael.Wojcik at microfocus.com Wed Feb 27 08:37:47 2008 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 27 Feb 2008 08:37:47 -0800 Subject: [splint-discuss] glib header and empty #define's In-Reply-To: <200802261519.06546.jakykong@theanythingbox.com> References: <200802261519.06546.jakykong@theanythingbox.com> Message-ID: <11352F9641010A418AD5057945A3A6590118B289@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces at cs.virginia.edu > [mailto:splint-discuss-bounces at cs.virginia.edu] On Behalf Of > Jack T Mudge III > Sent: Tuesday, 26 February, 2008 18:19 > > in /usr/include/glib-2.0/glib/gmacros.h > /* Guard C code in headers, while including them from C++ */ > #ifdef __cplusplus > # define G_BEGIN_DECLS extern "C" { > # define G_END_DECLS } > #else > # define G_BEGIN_DECLS ; > # define G_END_DECLS ; > #endif > > The point of this snippet seems to be to keep some > declarations from causing problems for C++ compilers, which > is fine. Not quite. C++ implementations will define "__cplusplus", so when this header is processed by a C++ implementation, G_BEGIN_DECLS will be defined as a macro that expands to "extern "C" {", and G_END_DECLS will be defined as a macro that expands to "}". extern "C" is C++ syntax that tells the implementation that the following declaration, or bracketted series of declarations, use the "C" linkage convention. It's used to tell C++ that the declarations refer to non-C++ code, for reasons that are irrelevant if you're not using C++. splint is not a C++ implementation, so it should not have __cplusplus defined (and won't, unless your configuration or one of the files you're processing erroneously defines it). > The definition G_BEGIN_DECLS and G_END_DECLS, then, should be "" in my > source file -- __cplusplus is NOT defined. No. Read the source again. If __cplusplus is not defined, then G_BEGIN_DECLS and G_END_DECLS are both defined as macros that expand to a semicolon - NOT an empty string. (I have no idea why the author of that header has them expand to semicolons; I can't offhand think of any situation where a linkage declaration would be appropriate in C++ and a semicolon would be needed in C. But a lot of GNU code is rather poor C.) > /usr/include/glib/gtypes.h:41:8: Parse Error: Non-function > declaration: > G_BEGIN_DECLS : int. (For help on parse errors, see splint -help > parseerrors.) This implies that you haven't included gmacros.h at all, or it would never see a token named G_BEGIN_DECLS. > I have tried adding #define G_BEGIN_DECLS ; to my source file, and splint > complains about a duplicate definition It's likely, then, that you have gtypes.h being included before gmacros.h, so the definition of the G_BEGIN_DECLS macro is only encountered after Splint tries to process gtypes.h. Can you produce a small example that demonstrates the problem? -- Michael Wojcik Principal Software Systems Developer, Micro Focus From brian.quinlan at iolfree.ie Wed Feb 27 11:20:47 2008 From: brian.quinlan at iolfree.ie (Brian Quinlan) Date: Wed, 27 Feb 2008 19:20:47 +0000 Subject: [splint-discuss] glib header and empty #define's In-Reply-To: <200802261519.06546.jakykong@theanythingbox.com> References: <200802261519.06546.jakykong@theanythingbox.com> Message-ID: <1204140048.5334.44.camel@akebono> On Tue, 2008-02-26 at 15:19 -0800, Jack T Mudge III wrote: > Greetings! > > This is my first message on this list. I've never used splint before > (although I just finished perusing the manual somewhat, and the program > appears enticing enough to be worth some work). > > I'm developing a small program to help me organize my homework a bit, and > thought I'd give splint a try with it. Created some source code that > compiles and runs flawlessly, but can't get past the glib header file > (parse error). I realize one option is to skip the header file alltogether, > but splint complains about unknown identifiers, and dies when I try to > treat an int (which was defined as a GString, but defaulted to int when > splint didn't know what a GString was, apparently) as a struct, and try to > dereference it. > > I did some hunting, and I'm pretty sure I narrowed the problem down to this: > > in /usr/include/glib-2.0/glib/gmacros.h > /* Guard C code in headers, while including them from C++ */ > #ifdef __cplusplus > # define G_BEGIN_DECLS extern "C" { > # define G_END_DECLS } > #else > # define G_BEGIN_DECLS ; > # define G_END_DECLS ; > #endif > > This file is included by every other header in the glib library, in this > case specifically in /usr/include/glib-2.0/glib/gtypes.h (which I included > in my source file). The point of this snippet seems to be to keep some > declarations from causing problems for C++ compilers, which is fine. I > generally don't use C++, so I'm not as familiar with some of these idioms. > > The definition G_BEGIN_DECLS and G_END_DECLS, then, should be "" in my > source file -- __cplusplus is NOT defined. However, splint feeds me this > error instead of skipping over it (since a blank definition does nothing): > > /usr/include/glib/gtypes.h:41:8: Parse Error: Non-function declaration: > G_BEGIN_DECLS : int. (For help on parse errors, see splint -help > parseerrors.) > > I have tried adding #define G_BEGIN_DECLS ; to my source file, and splint > complains about a duplicate definition (so apparently it's getting to the > definition in the first place). Unfortunately, I'm out of ideas except for > removing this code from my header files (since I'm not using C++, it > shouldn't do any harm to do that, but it seems drastic to me). > > Does anyone have some ideas as to how to get splint past these defines? > _______________________________________________ > splint-discuss mailing list > splint-discuss at mail.cs.virginia.edu > http://www.cs.virginia.edu/mailman/listinfo/splint-discuss Hi Jack, In the past when faced with similar parse problems, I've found it useful to use +keep on the splint command-line. See "Debug flags" at the bottom of: http://www.splint.org/manual/html/appB.html This keeps the temporary files (e.g., preprocessor output) generated by splint. This will show you exactly what splint is failing to parse. Perhaps more importantly, it might also give you an idea as to why splint is seeing the preprocessed code in this way. Bye, Brian From Ralf.Wildenhues at gmx.de Wed Feb 27 11:48:36 2008 From: Ralf.Wildenhues at gmx.de (Ralf Wildenhues) Date: Wed, 27 Feb 2008 20:48:36 +0100 Subject: [splint-discuss] glib header and empty #define's In-Reply-To: <1204140048.5334.44.camel@akebono> References: <200802261519.06546.jakykong@theanythingbox.com> <1204140048.5334.44.camel@akebono> Message-ID: <20080227194835.GC28596@ins.uni-bonn.de> Hi Brian, * Brian Quinlan wrote on Wed, Feb 27, 2008 at 08:20:47PM CET: > On Tue, 2008-02-26 at 15:19 -0800, Jack T Mudge III wrote: > > > > in /usr/include/glib-2.0/glib/gmacros.h > > /* Guard C code in headers, while including them from C++ */ > > #ifdef __cplusplus > > # define G_BEGIN_DECLS extern "C" { > > # define G_END_DECLS } > > #else > > # define G_BEGIN_DECLS ; > > # define G_END_DECLS ; These two lines look buggy. The gmacros.h on my system defines these macros to be empty here. > > #endif > > /usr/include/glib/gtypes.h:41:8: Parse Error: Non-function declaration: > > G_BEGIN_DECLS : int. (For help on parse errors, see splint -help > > parseerrors.) Make your own copy of the header, point splint at it with suitable -I switches, and either annotate the macros with /*@notfunction@*/ or put them in "#ifndef __LCLINT__" blocks (there is a newer macro for splint but I forgot its name). Hope that helps. Cheers, Ralf From jakykong at theanythingbox.com Wed Feb 27 14:12:09 2008 From: jakykong at theanythingbox.com (Jack T Mudge III) Date: Wed, 27 Feb 2008 14:12:09 -0800 Subject: [splint-discuss] [splint-discuss glib header and empty #define's In-Reply-To: References: Message-ID: <200802271412.19809.jakykong@theanythingbox.com> > Message: 8 > Date: Wed, 27 Feb 2008 08:37:47 -0800 > From: "Michael Wojcik" > Subject: Re: [splint-discuss] glib header and empty #define's > To: "Discussions about the Splint annotation-assisted static > ????????analysisproject"???????? > Message-ID: > ????????<11352F9641010A418AD5057945A3A6590118B289 at MTV-EXCHANGE.microfocus >.com> Content-Type: text/plain;???????charset="us-ascii" > > > From: splint-discuss-bounces at cs.virginia.edu > > [mailto:splint-discuss-bounces at cs.virginia.edu] On Behalf Of > > Jack T Mudge III > > Sent: Tuesday, 26 February, 2008 18:19 > > > > in /usr/include/glib-2.0/glib/gmacros.h > > /* Guard C code in headers, while including them from C++ */ > > #ifdef ?__cplusplus > > # define G_BEGIN_DECLS ?extern "C" { > > # define G_END_DECLS ? ?} > > #else > > # define G_BEGIN_DECLS ; > > # define G_END_DECLS ; > > #endif > > > > The point of this snippet seems to be to ?keep some > > declarations from causing problems for C++ compilers, which > > is fine. > > Not quite. > > C++ implementations will define "__cplusplus", so when this header is > processed by a C++ implementation, G_BEGIN_DECLS will be defined as a > macro that expands to "extern "C" {", and G_END_DECLS will be defined as > a macro that expands to "}". > > extern "C" is C++ syntax that tells the implementation that the > following declaration, or bracketted series of declarations, use the "C" > linkage convention. It's used to tell C++ that the declarations refer to > non-C++ code, for reasons that are irrelevant if you're not using C++. > > splint is not a C++ implementation, so it should not have __cplusplus > defined (and won't, unless your configuration or one of the files you're > processing erroneously defines it). > > > The definition G_BEGIN_DECLS and G_END_DECLS, then, should be "" in my > > > > source file -- __cplusplus is NOT defined. > > No. Read the source again. If __cplusplus is not defined, then > G_BEGIN_DECLS and G_END_DECLS are both defined as macros that expand to > a semicolon - NOT an empty string. > Wow. I know even less about C++ than I thought I did (and I didn't think I knew much). For a moment, I thought I may have made a typo, but reviewing the source again, you are absolutely correct. I read that code incorrectly. At least using the gcc compiler, the difference between a blank string and a semicolon in that context seems insignificant (they both compile, and they both do nothing. I'm not sure if there are any technicalities involved, however.) > (I have no idea why the author of that header has them expand to > semicolons; I can't offhand think of any situation where a linkage > declaration would be appropriate in C++ and a semicolon would be needed > in C. But a lot of GNU code is rather poor C.) > > > /usr/include/glib/gtypes.h:41:8: Parse Error: Non-function > > declaration: > > ? ? G_BEGIN_DECLS : int. (For help on parse errors, see splint -help > > ? ? parseerrors.) > > This implies that you haven't included gmacros.h at all, or it would > never see a token named G_BEGIN_DECLS. > Ok, I thought that implied that it hadn't seen the token, and assumed the token was an integer. gmacros.h is included by gtypes.h which is included by glib.h. By the time that token is ever used, it's already been defined. > > I have tried adding #define G_BEGIN_DECLS ; to my source file, and > > splint > > > complains about a duplicate definition > > It's likely, then, that you have gtypes.h being included before > gmacros.h, so the definition of the G_BEGIN_DECLS macro is only > encountered after Splint tries to process gtypes.h. > including gmacros.h is one of the first thing gtypes.h does, which is why I had concluded it was the #define itself that was causing problems. > Can you produce a small example that demonstrates the problem? I feel like an idiot right now. I went to re-produce this error, with a file "test.c" containing #include int main {return 0;} (which is all I needed to cause the error before). Which I proceeded to (attempt to) compile using the command gcc -l glib-2.0 test.c 2>&1|less And my screen promptly filled with several pages of error messages. Reading through the top few, include files weren't found. I compile a more elaborate, but very similar file perfectly using the make command in my working directory, so I went to check what I might be forgetting, only to find `pkg-config --cflags glib-2.0` hidden in my make file's CFLAGS variable. Splint passes -I to the preprocessor, and the above backtick expression evaluates to "-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include" on my system. That key oversight was apparently the source of this error. Thank you for your help (and your insight into what that macro was meant to accomplish). With any luck, this will be the only problem I run into! > > -- > Michael Wojcik > Principal Software Systems Developer, Micro Focus -- Sincerely, Jack Mudge jakykong at theanythingbox.com My GPG Public Key can be found at: https://www.theanythingbox.com/pgp.htm and Below. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20080227/78db21ac/attachment.bin From Michael.Wojcik at MicroFocus.com Thu Feb 28 07:12:08 2008 From: Michael.Wojcik at MicroFocus.com (Michael Wojcik) Date: Thu, 28 Feb 2008 07:12:08 -0800 Subject: [splint-discuss] [splint-discuss glib header and empty #define's In-Reply-To: <200802271412.19809.jakykong@theanythingbox.com> References: <200802271412.19809.jakykong@theanythingbox.com> Message-ID: <11352F9641010A418AD5057945A3A6590118B291@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces at cs.virginia.edu > [mailto:splint-discuss-bounces at cs.virginia.edu] On Behalf Of > Jack T Mudge III > Sent: Wednesday, 27 February, 2008 17:12 > Can you produce a small example that demonstrates the problem? > > I feel like an idiot right now. Don't. I'm sure most people on this list have plenty of experience with mysterious problems that suddenly become clear when examined from a different angle. Several times I've found things I overlooked while trying to produce a testcase for some issue. > I went to re-produce this error, with a file "test.c" containing > #include > int main {return 0;} > (which is all I needed to cause the error before). > Which I proceeded to (attempt to) compile using the command > gcc -l glib-2.0 test.c 2>&1|less > And my screen promptly filled with several pages of error messages. ... > so I went to check what I might be forgetting, only to > find `pkg-config --cflags glib-2.0` hidden in my make file's CFLAGS > variable. Splint passes -I to the preprocessor, and the above backtick > expression evaluates > to "-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include" on my system. > > That key oversight was apparently the source of this error. Hmm. I wonder if you have multiple versions of the glibc headers on your system? Maybe some with this issue, and some without? Though, if you have Splint running successfully now, it's probably not worth worrying about. You want Splint to check your code, not glibc's (not enough time in the day to do that...), so it generally doesn't really matter why a foreign header was causing trouble, if you can work around it. > Thank you for your help (and your insight into what that macro was meant to > accomplish). You'll see those C++ linkage macros in a lot of headers, as people generally want their C APIs available to C++ programmers as well, so it's something to be aware of. -- Michael Wojcik Principal Software Systems Developer, Micro Focus From ok at cs.otago.ac.nz Thu Feb 28 16:28:18 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Fri, 29 Feb 2008 13:28:18 +1300 Subject: [splint-discuss] glib header and empty #define's In-Reply-To: <200802261519.06546.jakykong@theanythingbox.com> References: <200802261519.06546.jakykong@theanythingbox.com> Message-ID: On 27 Feb 2008, at 12:19 pm, Jack T Mudge III wrote: > Greetings! > > This is my first message on this list. I've never used splint before > (although I just finished perusing the manual somewhat, and the > program > appears enticing enough to be worth some work). > > I'm developing a small program to help me organize my homework a > bit, and > thought I'd give splint a try with it. Created some source code that > compiles and runs flawlessly, but can't get past the glib header file > (parse error). I realize one option is to skip the header file > alltogether, > but splint complains about unknown identifiers, and dies when I try to > treat an int (which was defined as a GString, but defaulted to int > when > splint didn't know what a GString was, apparently) as a struct, and > try to > dereference it. > > I did some hunting, and I'm pretty sure I narrowed the problem down > to this: > > in /usr/include/glib-2.0/glib/gmacros.h > /* Guard C code in headers, while including them from C++ */ > #ifdef __cplusplus > # define G_BEGIN_DECLS extern "C" { > # define G_END_DECLS } > #else > # define G_BEGIN_DECLS ; > # define G_END_DECLS ; > #endif > The semicolons for G_BEGIN/END_DECLS bother me a lot. Suppose you have #include G_BEGIN_DECLS extern int x; extern void foo(char *); G_END_DECLS The result will be legal C++ or *illegal* C: ; is *not* a legal declaration in C. > This file is included by every other header in the glib library, in > this > case specifically in /usr/include/glib-2.0/glib/gtypes.h (which I > included > in my source file). The point of this snippet seems to be to keep some > declarations from causing problems for C++ compilers, which is fine. I > generally don't use C++, so I'm not as familiar with some of these > idioms. > > The definition G_BEGIN_DECLS and G_END_DECLS, then, should be "" in my > source file Why do you think the expansion should be empty when you have shown that the definition is a semicolon? > I have tried adding #define G_BEGIN_DECLS ; to my source file, and > splint > complains about a duplicate definition (so apparently it's getting > to the > definition in the first place). Unfortunately, I'm out of ideas > except for > removing this code from my header files (since I'm not using C++, it > shouldn't do any harm to do that, but it seems drastic to me). Try removing the semicolons from the #define directives; C *statements* end with semicolons or curly braces, but preprocessor *directives* are not statements and are terminated by newlines, not semicolons. From ok at cs.otago.ac.nz Thu Feb 28 17:06:05 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Fri, 29 Feb 2008 14:06:05 +1300 Subject: [splint-discuss] [splint-discuss glib header and empty #define's In-Reply-To: <200802271412.19809.jakykong@theanythingbox.com> References: <200802271412.19809.jakykong@theanythingbox.com> Message-ID: <30DF2A70-6E68-4B99-9D31-E7998CBE094B@cs.otago.ac.nz> > At least using the gcc compiler, the difference between a blank > string and a > semicolon in that context seems insignificant (they both compile, > and they > both do nothing. I'm not sure if there are any technicalities > involved, > however.) (a) What you are talking about is NOT a blank string " " or an empty string "" but an empty right hand side or empty expansion. (b) Accepting ";" as a declaration is a gcc extension. According to both the old (C89) and the new (C99) C standards, it is an outright syntax error. No ifs, buts, maybes, or technicalities: it's just not part of the language. (c) Most annoyingly, 'gcc -ansi' does not report this mistake in the header. What is the point of a command line switch to enforce a standard if it doesn't enforce the standard? You have to use 'gcc -ansi - pedantic' to get warning: ISO C does not allow extra ';' outside of a function but at least gcc *will* tell you this if you beg hard enough. It looks as though the header in question was written by someone pretty clueless. > >> (I have no idea why the author of that header has them expand to >> semicolons; I can't offhand think of any situation where a linkage >> declaration would be appropriate in C++ and a semicolon would be >> needed >> in C. But a lot of GNU code is rather poor C.) I can't think of any place where a linkage declaration would be appropriate in C++ and a bare semicolon would even be *legal* in standard C. > > I went to re-produce this error, with a file "test.c" containing > #include > int main {return 0;} > (which is all I needed to cause the error before). > Which I proceeded to (attempt to) compile using the command > gcc -l glib-2.0 test.c 2>&1|less I wonder how experienced you are with gcc? To get gcc to do anything resembling decent error reporting you need at a *minimum* gcc -ansi -pedantic -O2 -Wall There are plenty of other -W options you may wish to enable that are not included in -Wall. Some of the defects -Wall detects are only enabled if you have at least -O2.