l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2001 Dec 30 17:04

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Re: PATH_MAX
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Re: PATH_MAX

On Sun, Apr 29, 2001 at 11:22:19PM -0700, jdnewmil@dcn.davis.ca.us wrote:

> > Also, there is not guaranteed to be an actual limit to path strings -
> > and some library calls which return paths may return strings lonter
> > than FILENAME_MAX, I believe.  In the event that there is no actual
> > limit, PATH_MAX is not guaranteed to be defined, and FILENAME_MAX will
> > be defined to a very large number.
> Not guaranteed to be defined by what? Noncompliant implementations?

Note that I said, PATH_MAX, not FILENAME_MAX, which is not part of C
(POSIX, I believe - and I don't have the POSIX standards, but I think
it allows PATH_MAX to not be defined in the case that there is no
limitation).  This assertion came from the libc manual again.

I agree that glibc did The Wrong Thing by making FILENAME_MAX
arbitrarily high - the C standard specifically says (in a footnote,
not normative text, but stilll...) that in cases where there is no
practical limit, it should be set to a "recommmended" size for the
char array.

Most of the time, I've been impressed with GNU's library
implementation - this is certainly one instance where I'm not.

If it's set to 4096 on your system (and probably mine - didn't check),
the problem could be more outdated documentation than faulty
implementation, I suppose.

> The trouble with standards is that they can't please everyone.

You're telling me.  I'm absolutely thrilled about the new standard,
especially the vast amount of new math functions they've thrown in -
some of them should /really/ streamline calculation-intensive apps.
And yet, I kinda hoped there'd be a strdup() in there...


LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.