[GRASS5] Re: Contents of grass5 digest, Vol 1 #501, portability
Scott O'Donnell
odonnell at fsl.noaa.gov
Mon Oct 7 12:34:03 EDT 2002
Hi,
I'm relatively new to the developers list, although not new to using
and programing with GRASS. I think I'm beginning to appreciate the
difficulty of supporting so much software on so many different OS's.
While reading the discussions on 'portability', various writers
advocate the need to support their favorite OS and the variants
of C that the OS decision requires. While reading these discussions
and opinions about what should or shouldn't be supported, a presistent
question was raised in my mind.
What is the least level of portability that is required?
Has the GRASS development team decided to support software to
BSD-4.3 standards? ANSI standards? POSIX (1 or 2) standards? or
simply K&R?
If this were better understood or described, perhaps the recent
discussions of what functionality MUST be supported would be moot.
Is there a document that describes what level of portability must
be provided other than Marcus' list of guidelines to follow when
submitting software?
Thanks for helping me understand this issue,
Scott O'Donnell
---
grass5-request at grass.itc.it wrote:
>
> Message: 2
> Date: Fri, 4 Oct 2002 13:23:03 +0200
> From: Bernhard Reiter <bernhard at intevation.de>
> To: grass5 developers list <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] GRASS 5 and ANSI C
>
> --eNMatiwYGLtwo1cJ
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Thu, Oct 03, 2002 at 07:28:11PM -0700, Eric G. Miller wrote:
> > On Thu, Oct 03, 2002 at 10:14:06AM -0700, roger wrote:
>
> > > You can use the -ansi flag to force gcc to support full ANSI
> > > features and to disable non-ANSI features. If you then use
> > > -pedantic the compiler will reject any code that is not ANSI
> > > standard. The error.log will contain a list of uncompiled
> > > code.
> >=20
> > Generally speaking, K&R C is perfectly valid ANSI C89/90.
> > So, -ansi -pendantic might not change much. =20
>
> Probably K&R C refers to the first revision of the book.
> AFAIK the first revision was not ANSI C.
>
> > C99 requires valid prototypes (not just declarations like "void
> > foo();").
>
> We don't want C99 anyway. :)
>
> --eNMatiwYGLtwo1cJ
> Content-Type: application/pgp-signature
> Content-Disposition: inline
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
>
> iD8DBQE9nXoXh9ag3dpKERYRAjcRAKDGuNJ9KSyI7VQu2s20+DtNTo9ghgCfUgPd
> Pt0Vce8R7/v1F7qSoyCLoWU=
> =zWwb
> -----END PGP SIGNATURE-----
>
> --eNMatiwYGLtwo1cJ--
>
> --__--__--
>
> Message: 3
> From: Glynn Clements <glynn.clements at virgin.net>
> Date: Fri, 4 Oct 2002 13:11:21 +0100
> To: "Eric G. Miller" <egm2 at jps.net>
> Cc: grass5 developers list <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] Portability issues
>
> Eric G. Miller wrote:
>
> > > Some of these could simply be replaced with ANSI functions, while
> > > others suggest that new functions should be added to e.g. libgis to
> > > improve portability.
> > >
> > > Some comments on specific functions:
> > >
> > > + open close creat read write lseek truncate
> > >
> > > Many of these could probably be replaced with the ANSI stdio
> > > equivalents.
> >
> > libgis uses file descriptors heavily, so POSIX functions are
> > useful/mandatory. ANSI doesn't have a truncate() or ftruncate().
>
> I'm not really concerned about libgis. Implementing multiple versions
> of core functions is feasible; doing the same for all the individual
> modules isn't.
>
> truncate() is only used by d.labels, and its use there appears to be
> unnecessary.
>
> Basically, I'm suggesting that modules which simply need to read/write
> files should prefer the ANSI stdio mechansims over the POSIX ones.
>
> > > + mkdir chdir opendir closedir readdir
> > >
> > > The ANSI libraries don't deal with directories. However, any system on
> > > which GRASS runs will have equivalent functionality; we just need to
> > > provide a portable interface.
> >
> > Not a bad idea to have system interface (though Winders supposedly is
> > supporting POSIX these days...).
>
> NT has a POSIX subsystem, but it's "bare" POSIX.1 (e.g. no sockets),
> and it's completely detached from the rest of Windows (i.e. a POSIX
> program can't use the Win32 API).
>
> > > + snprintf
> > >
> > > C9X defines this, so in a couple of decades it won't be a problem. For
> > > now, a wide variety of solutions are possible, all with their own
> > > advantages and disadvantages.
> >
> > Couple of *decades*! ;^) I think mostly we'd rather have an asprintf()
> > available...
>
> Yeah, but asprintf() isn't standard either, and requires non-trivial
> code changes.
>
> This simplest workaround is an snprintf() look-alike which simply
> ignores the length option, and passes the rest to vsprintf(). In most
> of the cases which I examined, the caller doesn't actually check
> whether the buffer was too short, so you would probably still get
> erroneous behaviour.
>
> > > + sigaction sigemptyset
> > >
> > > Only used by r.mapcalc. signal() can be used instead, although
> > > signal() has problems of its own (BSD-vs-SysV signal semantics,
> > > general lack of flexibility).
> >
> > sigaction is POSIX, so should be fairly portable by now. ANSI only
> > minimally describes signals, hence the BSD vs. SysV, etc...
>
> r.mapcalc only actually uses it to set a flag if SIGFPE occurs, so
> signal() would probably suffice here.
>
> > > + putenv
> > >
> > > Used by XDRIVER; it probably doesn't need to be portable.
> >
> > Why not setenv()?
>
> setenv() is BSD 4.3. putenv() is POSIX, BSD 4.3, SVID 3. Neither are
> ANSI. The C99 description of getenv() says:
>
> The set of environment names and the method for altering the
> environment list are implementation-defined.
>
> > > + gethostname
> > >
> > > Used by G__machine_name(), which is sensible enough. Presumably
> > > equivalent functionality is available on any networked system (and, on
> > > non-networked systems, you don't really need a per-machine
> > > identifier).
> >
> > That's mostly for the tmpfile thing these days, no? Probably could
> > think about getting rid of it if the whole mapset permissions thing
> > is redone.. (Hmm, there's also that email interface...).
>
> The only caller of G__machine_name() is G__temp_element(), which is
> presumably to handle the case where GISDBASE is on a network share.
>
> --
> Glynn Clements <glynn.clements at virgin.net>
>
>
> --__--__--
>
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>
> End of grass5 Digest
--
Reality is that which, when you stop believing | Scott O'Donnell
in it, doesn't go away. | odonnell at fsl.noaa.gov
-- Philip K. Dick | 303·497·6562
More information about the grass-dev
mailing list