> From [EMAIL PROTECTED] Thu Nov 7 18:30:04 2002 > Date: Thu, 07 Nov 2002 15:26:57 -0800 > From: Terry Lambert <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
