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 Message-ID: <3DCAF6C1.D01805FE@mindspring.com> References: <3DCADE51.2090607@acm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Tim Kientzle wrote: > Terry Lambert asked: > > Any chance we could get rid of all externally visable symbols that > > are not defined as being there by some standard, and not just __sF, > > since we are breaking the FORTRAN compiler and other third party > > code already? > > This cannot be entirely done if you still want to > manage library bloat. In short, library routines > have shared interfaces between them---common variables > or common functions---that are internal to the library > and should not be used by applications. > > To avoid this, you would have to bundle library functions > together, which causes bloat. Worse, you would have to > avoid or drastically limit your use of macros. (Any > macro that uses one of these internal symbols generates > a dependency in the compiled application.) > > It _would_ be a good idea to document any internal library > symbols used by macros. Removing such symbols is a > good way to break existing compiled applications. > > Library design involves a lot of tradeoffs. I don't buy this. 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. -- Terry 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?3DCAF6C1.D01805FE>