| phil-news-nospam@ipal.net 2007-05-18, 7:17 pm |
| I've found at that the supposed-transition interface for large file support
is indeed not a transition, but a permanent "solution" to a non-problem.
But we're stuck with it.
Programming applications around this is rather easy. But what I have is a
library with several interfaces that involve passing along data that is
affected by whether large file support is enabled or not. For example one
of the function groups is an alternative to ftw/fts functions to recurse
through deep file trees. Part of what it does is pass back to the caller
a pointer to the stat buffer of each filesystem item it finds during the
recursion. That can clearly be a problem if some programs expect the old
data type members, and other programs expect large file support.
So I'm trying to decide what is the best approach to this. Should I just
bite the bullet and make the entire library only use large file support,
creating issues with programs that for whatever reason cannot or must not
use LFS? Or should I make parallel versions of the library for each? Or
should I just add some new functions/interfaces where LFS is a factor and
support both in one library? Or should I try to invent some kind of data
type transparency?
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2007-05-18-1542@ipal.net |
|------------------------------------/-------------------------------------|
|