8 bit os_f handles

[Daniel Ellis]

Tom Hughes writes:
 > In message <200003282012.MAA29499 at purple.trimedia.sv.sc.philips.com>
 >           "Jonathan Coxhead" <jonathan at doves.demon.co.uk> wrote:
 > 
 > >    This is normal practice anyway. If a UNIX makefile contains the
 > > line
 > >
 > >       prog: prog.c
 > >          cc -o prog prog.c -lm
 > >
 > > do you think it should also have
 > >
 > >       prog: /usr/lib/libm.a
 > >
 > > ? Because this is *not* normal practice.
 > 
 > Indeed, although I have been known to do it on occasion. Surely the
 > point here though is that any code using os_f will have to include
 > os.h either directly or indirectly, and the Makefile would normally
 > have a dependency on that for any source file using os_f.

Precisely.  The only ambiguity is whether the date stamp on os.h is
sufficiently late enough.  If you unpack an archive the files will
usually have date stamps according to their source, so if I recompiled
my sources yesterday, the new library was written the day before
yesterday, and I install it today, then I don't suppose my code will
get remade by the make utility...

I suppose the installation should stamp all the header files at the
moment of installation.

I don't really see why defining os_f as junk is any better than
creating a new environment where os_f is os_w and the old api is
#defined to be the new one.  It would certainly be much less work to
simply make it an int absolutely!

-- 
Dan Ellis
Software Engineer
Climate Physics Group
Mulard Space Science Laboratory