[bug #2180] (grass) Re: [GRASS5] C and C++ compiler changes?

[Glynn Clements]

Request Tracker wrote:

> No, in the sense that the "user apparent" changes are with the C++ part.
> But unfortunately, GCC 3.3.1 for example has some bugs in optimization
> and inlining meaning that we will have some rough times with compilation
> failures reports that may be caused by bugs in the compiler and not in
> the code (for example some version(s) of glibc doesn't compile with it
> and one can compile a Linux kernel with it that will cause bugs (in my
> case this was reboot) : but compilation succeeds...; so imagine the 
> hell if a glibc compiles but is buggy!).

Actual compiler bugs aren't necessarily the only issue. GCC's
optimisation has been getting increasingly aggressive over time. 
Consequently, whereas you used to be able to get away with ignoring
C's aliasing rules, doing so now will often result in broken code when
optimisation is enabled.

Given the age and general clunkiness of much of GRASS' code, the
probability that aliasing bugs exist is rather high. Unfortunately,
such bugs can be hard to track down.

> As for the GNU libc, this is also a problem at the moment because glibc
> is not only libc, it's a bundle of libraries and extensions and,
> unfortunately, people use to develop with glibc forgetting that some
> features are GNU idiosynchrasies and thinking that there are "standard"
> and compilation may fell with other libraries, or even fail compiling
> against another version of glibc since these extensions change from
> time to time (I have experienced this too this week-end).

We seem to have a fairly good record on these issues. Most of the
extensions which used to be in the code weren't glibc-specific, but
have been removed anyhow. E.g. snprintf() and setenv() are
non-standard but common, but I think that these have both been
eliminated (actually, setenv() is used if it exists but putenv()
doesn't).

> Synthesis: there may be in the future reports about C++ (need to be
> fixed because the 3.x series of GCC has changed a lot of things in 
> this area) and reports about compiling failures that are caused by
> particular mixes between versions of GCC and glibc but not because
> GRASS code is in itself buggy.

While C++ is inherently much more problematic (for portability) than
C, it doesn't help that the r.terraflow authors don't appear to have
given a particularly high priority to portability. Some of the issues
(e.g. the gcc-isms in the Gmakefile) are simply down to "works on my
system" syndrome.

> I agree with you that we must stick as much as possible to C, and I
> add strict ANSI/ISO C and strict POSIX functions, clearly making the
> distinctions between what is standard and what is not: we need in this
> case to provide the libraries or to set a dependency against one open
> implementation.

Agreed. Ideally I would like to be able to isolate the Unix-isms so
that GRASS could run natively on Windows (i.e. without requiring
Cygwin). There aren't actually that many issues; most of GRASS is
plain ANSI C. Probably the biggest single issue is the use of
system(), some of which is totally gratuitous, e.g. the use
system("rm ...") and system("mkdir ...").

BTW, there is a script (tools/sql.sh) which uses "nm" and "ldd" to
obtain symbol and library dependencies and feed them to an SQL
database. This can be used to identify which GRASS libraries and
modules require non-ANSI functionality.

Incidentally, this sort of thing was the main reason that I added
support for building shared libraries; i.e. so that "nm" and "ldd"
would distinguish between the dependencies between modules and GRASS
libraries and those between GRASS libraries and system libraries.

There are a few cases where it has demonstrated dubious dependencies. 
E.g. the functionality in unix_socks.c results in libgis depending
upon the socket functionality (which is built into glibc, but may be
in e.g. libsocket on other Unices), although it is only actually used
by the raster and driver libraries.

-- 
Glynn Clements <glynn.clements at virgin.net>