🚀 go-pugleaf

I posted a request recently asking for tips on portability, and offered to
write a portability guidelines document based on the replies and my own
experiences.

Well, I've had a lot of positive replies, for which I'm grateful.

I've also had several replies along the lines of 'FSF is not interested in
systems other than GNU unix (which will be a unix in the style of SunOS) and
don't want to know...'.  It wasn't obvious whether most of these people were
gnu representatives stating their policy, or gnu detractors criticising the
FSF.  I'm assuming the former.

I'd like to explain what I'm trying to do, and why, and how it will help us:

I'm from Britain, and the only machine I have is an Acorn Archimedes. There
is very little likelihood of me ever affording a Unix system, unless of
course a free Gnu unix ever arrives on the Archie. However I'm a reasonably
competant programmer and I'd like to support the Gnu project -- i.e. any
major projects I write based on my machine should be easily adaptable to the
Gnu environment.  Therefore, when I write code for this completely obscure OS
(obscure? - this is a system with no file extensions... !) I do it so that it
compiles on bsd Unix without change.

My programs also compile on VMS, DOS (all compilers), Amiga, Atari, Mac, and
(I've been told) others, though I forget some of the more obscure ones.

Now, it took me a long time to learn to write code in this style -- every
time I thought I'd cracked it, some other system came along to astound me
with titbits like 'entry is a keyword in this C compiler, so you can't use it
as a variable name...'

I want to write down my (and your) experiences so that others in my situation
can learn from my mistakes.

That's my primary reason.  My secondary reason is more selfish; I want
the gnu tools on my machine :-)  I've just recovered from porting gnu sort
(via the MSDOS version) and am asking myself why did I need to do it? -
a program which does nothing external at all except read in files and
write out files should be 100% portable.  I've ported umpteen packages
to the Archimedes and the majority of them have taken far more time that
I'd like.

I think I know part of the reason I received so much critical mail;
I suspect people thought I was advocating that you write code like this,
for instance:

#ifdef MSDOS
  sprintf(fname, "\\tmp\\%s.ext", file);
#endif

#ifdef ARCHIMEDES
  sprintf(fname, "$.tmp.%s-ext", file);
#endif

#ifdef UNIX
  sprintf(fname, "/tmp/%s.ext", file);
#endif

... If I saw code like that I'ld throw up my hands in horror, as most
of you would.  I suspect many people defending gnu's stance of 'no systems
except gnu unix' are probably thinking of stuff like that when they suggested
I didn't bother writing a portability doc.

However, all I'm suggesting is nothing but standard programming practice,
such as (for this concrete example):

  sprintf(fname, "%s%c%s%c%s", TMP_PATH, DIR_SEP_CH, file, EXT_SEP_CH, "ext");

This simple expression is more portable than the unix line above, and
localises the changes needed to one header file, rather than several
occurances throughout the file.

The point is that writing code in this way doesn't compromise your source at
all, and it makes it *so* much easier for users of other systems to adapt
your programs to their machines.  And there is a big win from this: you get a
much larger pool of programmers willing to work on, bug fix, improve and
extend gnu utilities so that the gnu project becomes stronger.

So, in summary: I'm not suggesting that FSF staffers devote any time at all
to writing code for non-gnu systems.  I'm suggesting that people writing new
projects which they want to disseminate via gnu should take a little care at
the outset not to introduce unneccesary non-portable features.  The code
won't be bastardised at all and benefit will accrue to the gnu project.

Graham Toal <gtoal@ed.ac.uk>
[PS A lot of people will be chuckling, saying - hey, it's all right for other
people to worry - but *my* C is straight out the book...; I used to say that
too until I got my hands on Acorn's extremely strict ANSI C compiler... boy,
does it find the bugs other compilers don't reach :-)]
-- 
(* Posted from tharr.uucp - Public Access Unix - +44 (234) 261804 *)