From owner-cvs-all Tue Sep 28 10:36:26 1999 Delivered-To: cvs-all@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 16A7715695; Tue, 28 Sep 1999 10:36:21 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA91250; Tue, 28 Sep 1999 10:36:15 -0700 (PDT) (envelope-from dillon) Date: Tue, 28 Sep 1999 10:36:15 -0700 (PDT) From: Matthew Dillon Message-Id: <199909281736.KAA91250@apollo.backplane.com> To: Marcel Moolenaar Cc: Peter Wemm , Marcel Moolenaar , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libtermcap termcap.c References: <19990928145514.05BF31CBF@overcee.netplex.com.au> <199909281624.JAA90525@apollo.backplane.com> <37F0F581.C8CB9CE2@scc.nl> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk :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 : :-- :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