Re: 64 bit time_t changes

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sat, Mar 22, 2008 at 06:54:06PM -0400, Christos Zoulas wrote:
 > | Third -- if we're going to do it, what other changes should we make at
 > | the same time?
 > 
 > - The changes mentioned in shlib_version
 > - Normalize some more types [size_t for example] across platforms
 > - Hide stdio structures
 > - Kill compatibility code
 > - remove __RENAME'd stuff
 > 
 > Anything else?

 - add expansion space to struct lastlogx;
 - make fileno() not a macro;
 - try to work out a way to make users of stdio macros depend on some
   private libc symbol, so we can at least identify them;
 - kill getdirentries();
 - figure out if there's anything we should do in advance for handling
   the Large File Summit interface crud (probably not, but...);
 - do we want to extend the backend nsswitch interface at all?
 - add expansion space to any semi-abstract struct someone might
   declare on the stack and pass to a *_r function;
 - maybe add expansion space to everyone's jmp_buf? I can't think of
   any reason we'd want it, but if some reason should come up and we
   don't have it, it'll hurt, and it doesn't cost much;
 - add expansion space to struct stat?

Basically one could add maybe-useful expansion space almost anywhere
but it's not clear what the proper tradeoff is between bloat and
legitimate future needs.

I'm also wondering if there are internal limits in the timezone code
that ought to be increased.

oh, and we should consider flatly removing a few of the
old/outdated/unsafe interfaces, or at least the less standards-
encrusted ones, like perhaps mktemp(). Also, sigvec() and its friends,
although I guess those could be usefully kept in libcompat. And there
are probably a bunch of old ioctls we could deprecate and not miss.

-- 
David A. Holland
dholland%netbsd.org@localhost