OPEN_MAX and other constants - are they desireable?

Moderator, John Quarterman std-unix at ut-sally.UUCP
Fri Nov 15 23:10:14 AEST 1985


Date: Thu, 14 Nov 85 17:21:36 pst
From: saber!msc at ihnp4.uucp (Mark Callow)

> From: Kee Hinckley <harvard!wanginst!apollo!nazgul>
> 
> In article <3430 at ut-sally.UUCP> you write:
> > Date: 06 Oct 85 18:36:07 +1000 (Sun)
> > >From: Robert Elz <munnari!kre at seismo.CSS.GOV>
> ...
> > I suggest deleting all of the constants, and instead specifying
> > a library routine, which when handed a name defined in <limits.h>
> > will return the associated constant.
> > 
> 
> One problem with this is that a piece of code may want to #if off of
> particular constants.  For instance, if I discover that the amount
> of memory I have is too small, and I don't have virtual memory then
> I might want to use temporary files.
You can do this just as well with an if statement at runtime.  Then
if someone decides to add more memory to their machine they don't
have to recompile their world to take advantage of it.

> ...but it would not work out nearly as well if I had to
> make that kind of decision at runtime.
Why not?  The penalty is a small increase in the size of the
binary.

limits.h and all similar kinds of wired-in constants are the pits.
What happens in a network environment?  Do your servers have one
copy of the program for each client configuration?  Of course not.
What does a computer manufacturer do?  Have a different software
release for each system configuration?  Of course not.  You
either end up in the least common denominator trap or you ignore
limits.h and implement the library function suggested by kre.

Volume-Number: Volume 3, Number 19



More information about the Mod.std.unix mailing list