Re: encapsulating directory operations

Richard Heathfield <rjh@cpax.org.uk> wrote:

 
Software houses need C90 for the same reason the government needs
IBM 1311s (unless they've finished migrating off them now),
cassette players, WW2 crypto keys, and the boot passwords for
those early 1990s PCs lurking in the cellar.
 
I shudder to think how much C90 code is out there, but it has to
be /at least/ in the region of 10^9 LOC, much of it in the
military arena, medical applications, and particularly the world
of comms. Letting C90 compilers fall off the radar (e.g. by
society forgetting how to program in it) really could be a
stupendously bad idea, for all the reasons that people overlook
when they shrug and say `I expect it'll all turn out fine'.

Clearly there is a lot of old code there.  I am not sure why
you think that C90 is very special here.  I mean, goverment
loves standards and for goverment project may mandate use
of "standard" language, which could mean C90 in relevant
period.  However, business had tendency to use whatever their
compilers supported, which frequently meant using vendor
extentions.  Due to extentions, I suspect that there is very
little pure C90 code.  Even if C90 was mandated it is not
clear if C90 was really deliverd.  More precisely, when you
look at small snippets of C code there is good chance that
they will be valid regardless of version of C that you use.
However in large codebase one can expect some constructs that
are not valid C90.  Even for code born as pure C90, there is
notrivial chance that maintanence introduced constructs
from later C standards.

AFAICS C99 and C11 did not introduced major incompatibilities
with C90.  OTOH some vendor extentions to C90 were
standarized in C99 and C11.  So, it is reasonable to suspect
that amount of say C99 code is significantly larger
than C90 code.  Or may be better to say that deviation of
C code from C99 is probably smaller than deviation from C90.

Concerning new code it makes sense to avoid constructs that
are made illegal in later standard, that is write to the
latter of later standard even if you use only constructs
available in C90.  And concerning constructs not in C90,
I find ability to mix declarations and statements important
to readability.  So any code that I write now is unlikely
to be valid C90 for this (technically trivial) reason.
For computational code multidimensional arrays are
useful.  In general purpose code sizes of arrays are
typically only known at runtime, so it is natural to
use variable modified types.  Other people may find useful
some other features of C99 or later standards, so there
is incentive to go beyond C90.

There is also historic aspect.  C90 is part of history and
I fully support preserving it (specification and actual
programs) as historic artifacts.  But I also think that
C90 should be retired from practical use, that is code
should be modernized to comply with later standards.
If code needs to be very portable, than C90 compatibility
makes sense, but for most code it it better to take
advantage of newer features.

BTW: In the past I used to point out to students that some
features that they use in their programs are not C90 but
say C99.  But now I do not think that it is worth to
bother students with information about C90.

--
                              Waldek Hebisch