of course!

[Geoff Clare]

In article <1989Nov22.224209.28911 at athena.mit.edu> jik at athena.mit.edu (Jonathan I. Kamens) writes:
>In article <1051 at root44.co.uk> gwc at root.co.uk (Geoff Clare) writes:
>=            Another is that PATH_MAX might not be defined (it should
>=always be obtained via pathconf() in portable applications).
>
>  Not convinced this is a major problem.  I've yet to run into a Unix
>programming environment that doesn't somewhere in a header file give
>you some indication of the maximum path length,

I don't know of any current systems like this, either, but it's entirely
possible there will be systems like this in the near future.  That's
because POSIX.1 says that PATH_MAX is optional and provides pathconf()
to obtain its value at runtime.

Even if there is a PATH_MAX in <limits.h> it should not be used to
dimension an array which is assumed to be able to hold any path name,
because the actual maximum is allowed to be higher.  E.g. an NFS
mounted file system might allow longer names than local file systems.

>  I therefore fail to see why malloc is a better choice than an
>automatic variable.

Given that the length of an array to hold all possible path names is
not known until runtime, you have no choice but to use malloc().  So
why not just malloc only what you need?

Your objections on performance grounds are unfounded.  Only the first
call to the routine will be slower.  After that malloc() will just
adjust a few pointers.
-- 
Geoff Clare, UniSoft Limited, Saunderson House, Hayne Street, London EC1A 9HH
gwc at root.co.uk  (Dumb mailers: ...!uunet!root.co.uk!gwc)  Tel: +44-1-315-6600