[Geany] [PATCH] Fixes for warnings and portability

[Nick Treleaven]

On Tue, 19 Feb 2008 13:41:16 -0500
"Daniel Richard G." <skunk at iSKUNK.ORG> wrote:

[...]
> On Tue, 2008 Feb 19 14:08:28 +0000, Nick Treleaven wrote:
> >
> > > > The biggest portability issue, however, is one that a patch is
> > > > not well-suited to fix: the use of C++-style comments in C
> > > > code. GCC allows this, but will readily warn that "C++ style
> > > > comments are not allowed in ISO C90", and Unix compilers almost
> > > > universally choke on them as a syntax error.
> > 
> > Oh noes ;-) Luckily I mainly use C-style comments. Again I had
> > wrongly assumed that modern compilers would allow this.
> 
> I believe C++-style comments are allowed as of C99. In practice,
> however, C99 means either GCC, Intel's icc, or (maybe) newer versions
> of the Solaris/HP-UX/etc. C compiler than I've ever tried.
> 
> In my experience, ANSI C89 plus a few ubiquitous extensions (e.g.
> long long) is the sweet spot for portability, at least across most
> Unix platforms. If the platform can't handle ANSI C, it won't be able
> to build GTK+ anyway ^_^

Thanks for the info. I'll try to write ANSI C89.

[...]
> I have a standard set of flags:
> 
> CFLAGS = -O0 -g3 -pedantic -fno-common -pipe -W -Wall -Wcast-align \
> 	-Wcast-qual -Wconversion -Wformat=2 -Winline -Wpointer-arith \
> 	-Wshadow -Wundef -Wno-unused-parameter -Waggregate-return \
> 	-Wnested-externs -Wstrict-prototypes
> 
> Some of those -W... flags may be too much, but at a mininum
> everything up to and including -Wall. I particularly recommend
> -fno-common; that one will catch multiply-defined symbols.

Thanks, I'll update my flags soon.

> Oh, and I also use a custom script to quickly review all the warnings 
> produced in a build. See attached. Give it a file containing the
> build output, warnings and all, and it'll output a nice list like
> 
>    1314 passing argument N of 'blah' with different width due to
> prototype 406 C++ style comments are not allowed in ISO C90
>     399 missing initializer for member 'Foo::bar'
>     300 passing argument N of 'blah' as floating rather than integer
> due to prototype 170 passing argument N of 'blah' as 'float' rather
> than 'double' due to prototype 118 passing argument N of 'blah' as
> unsigned due to prototype 66 passing argument N of 'blah' as signed
> due to prototype 47 cast discards qualifiers from pointer target type
>    [...]

Sounds useful, I'll keep it handy.

> > > * highlighting.h: The "gboolean" type already indicates that these
> > > fields are true-false flags, and GCC complains about portability
> > > if a bitfield specifier is used.
> > 
> > OK, maybe I'll change them to integer types so they can share a
> > DWord with bitfields.
> 
> Is there a need for bitfields here? I mean, it's nice to have a
> true/false value occupy one bit instead of an int (gboolean), but the
> code is a lot cleaner with the latter approach. You rarely see
> bitfields outside of device/system code, and places where you really
> need to do bit-packing (e.g. a struct that lets you get at the parts
> of an IEEE float).

OK, I guess it's probably not necessary for that amount of memory
(probably only a few 100 bytes for typical users), and gboolean is
clearer.

Regards,
Nick