Date: Tue, 28 Sep 1999 10:36:15 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Marcel Moolenaar <marcel@scc.nl> Cc: Peter Wemm <peter@netplex.com.au>, Marcel Moolenaar <marcel@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libtermcap termcap.c Message-ID: <199909281736.KAA91250@apollo.backplane.com> References: <19990928145514.05BF31CBF@overcee.netplex.com.au> <199909281624.JAA90525@apollo.backplane.com> <37F0F581.C8CB9CE2@scc.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
:I don't think that's a particular good argument. You don't simply add a
:field to sigaction. You create a complete new interface to handle all
:the compatibility issues. To put it differently;
:the argument holds if it is done for every structure there is, not just
:for sigaction alone.
:
:> Also, other operating systems may implement additional
:> fields that termcap doesn't know about.
:
:Yes, but is this termcap not specific to this OS? Isn't it our goal to
:provide an efficient and compatible libc? Efficiency is improved.
:Compatibility isn't broken...
For the moment. Doesn't mean it's gonna stay that way though!
The reason for programming defensively is not to make the program work
in current systems, but to make sure the program continues to work in
future systems. It's just plain common sense. If you make assumptions
about how structures will or will not change over time (for example,
you are assuming that sigaction will never ever change for the entire
rest of the life of FreeBSD), then all you wind up with in a few years
time is a mess.
We maintain hundreds of programs while at the same time make major changes
to the operating system core and libraries. Programming methodologies
such as bzero'ing structures has prevented a lot of grief over time.
Let me give you an example. For a very long time the fileno() macro
in gnu libc directly addressed a field offset way deep into the FILE
structure. Someone thought that making fileno() a macro would be more
efficient then making it a library call. Unfortunately, the programmers
who used it thought it was a library call. So when the time came to
make a modification to the FILE structure suddenly the shared library
stopped working for a large number of programs. "Oops". That one mistake
caused no end of pain for a period of almost a year.
FILE was supposed to be an opaque structure but the macro screwed it up.
This is just one example of why most well-written libraries use opaque
structures. For the same reason, system-supplied structures must be
considered to be as opaque as possible. In otherwords, you only use those
fields you are allowed to use and make no assumptions about the rest.
:I understand that, but portability isn't an issue in this case, is it?
:And as for compatibility; it now uses sigemptyset, and thus is finally
:compatible.
Portability is always an issue. You never purposefully make something
unportable when it costs nothing to keep it portable.
-Matt
Matthew Dillon
<dillon@backplane.com>
:
:--
:Marcel Moolenaar mailto:marcel@scc.nl
:SCC Internetworking & Databases http://www.scc.nl/
:The FreeBSD project mailto:marcel@FreeBSD.org
:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909281736.KAA91250>