Date: Thu, 7 Nov 2002 18:37:20 -0500 (EST) From: Ray Kohler <ataraxia@cox.net> To: kientzle@acm.org, tlambert2@mindspring.com Cc: current@FreeBSD.ORG Subject: Re: [PATCH] note the __sF change in src/UPDATING Message-ID: <200211072337.gA7NbK1m082069@arkadia.nv.cox.net> In-Reply-To: <3DCAF6C1.D01805FE@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> From owner-freebsd-current@FreeBSD.ORG Thu Nov 7 18:30:04 2002 > Date: Thu, 07 Nov 2002 15:26:57 -0800 > From: Terry Lambert <tlambert2@mindspring.com> > To: kientzle@acm.org > Cc: current@FreeBSD.ORG > Subject: Re: [PATCH] note the __sF change in src/UPDATING > > > Specifically, I do not buy the idea that there is a necessity > for the existance of data interfaces, as opposed to procedural > interfaces. > > And procedural interfaces are fixable with weak symbols. > > The thing that's screwing us with __sF is that it is a data block > that's directly referenced without the use of an accessor function, > and thefore there are global data references, rather than accessor > or mutator function references. > > As a result, when the underlying data changes, the code that has > already been compiled to reference it, must also change. > > This problem has already been fixed with errno. It has already > been fixed with strerror() (though unfortunately, the sys_errlist[] > and sys_nerr references remain unwrapped). It has been fixed in > many other places (e.g. the curses library used to export row and > column count integers, and doesn't any more). > > It's very obvious to me that defining a *non-inline* function to > return the correct __sF entry by entry ID will erase this problem > for a future version of FreeBSD, while leaving the __sF invisible > for a revision cycle, so that new applications will get the > function reference, and old applications will get the __sF reference > they expect, and continue to compile and link correctly. Hear hear, I agree. There's no need to expose what ought to be "private" data to the world, especially when we can get the additional benefit here of letting us play with the implementation. - @ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211072337.gA7NbK1m082069>