l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
December 2: Social gathering
Next Installfest:
TBD
Latest News:
Nov. 18: Club officer elections
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, 29 Apr 2001, Micah Cowan wrote:

> On Fri, Apr 27, 2001 at 08:08:04PM -0700, jdnewmil@dcn.davis.ca.us wrote:
> > On Fri, 27 Apr 2001, Henry House wrote:
> > 
> > > The header file linux/limits.h defines PATH_MAX, which is alegedly the limit
> > > on path lengths. Is there a portable way to get the maximum path length?
> > 
> > I think the closest you can get is:
> > 
> > #include <stdio.h>
> > char fname[ FILENAME_MAX ];
> 
> >From the libc manual:
> 
>     *Usage Note:* Don't use `FILENAME_MAX' as the size of an array in
>      which to store a file name!  You can't possibly make an array
>      that big!  Use dynamic allocation (*note Memory Allocation::)
>      instead.

"Don't use the method specified by the ANSI/ISO C Standard for declaring
space to store filenames, because it works like shit in our
implementation!"  whatever...

For my system, FILENAME_MAX is defined as 4096.

  char fname[ 4096 ];

is absolutely "possible" to make, though they could have defined it to be
2^31-1 and it wouldn't be.  It might not be a good idea to declare lots of
4096 byte buffers locally in functions, but if you need that many filename
buffers simultaneously, it won't matter whether you put them on the stack,
in global memory, or in heap.... they all have to be there.

Dynamically sizing your storage to handle variable sized buffers is
certainly the best approach, but it can be very difficult to get it right
and still perform well.

> 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?

To reiterate:

"FILENAME_MAX is an ... integral constant ... that is the size needed for
an array of char large enough to hold the longest file name string that
the implementation guarantees can be opened; ... "

The standard says nothing about whether filenames in the filesystem may be
longer than FILENAME_MAX-1, only that the implementation makes no
_guarantee_ that if a filename longer than that is passed to the fopen
call that it will be able to open it.  A compliant implementation may
choose to define FILENAME_MAX as 14, yet be able to handle filenames of
10000 characters. The vendor would then be compliant, but this might not
make its users very happy.  Setting FILENAME_MAX to an impractically large
number is counterproductive as well, but Gnu's Not Universal.

The trouble with standards is that they can't please everyone.  The
advantage of standards is that if you follow them, your program should run
correctly on any compliant implementation. It just doesn't sound like FSF
is interested in complying with this standard.  You may find yourself
agreeing with them, but you risk noncompliance, and therefore portability,
if you don't follow the standard.  That may not be the end of the world,
but I think it is better to leave that choice to the user than have the
library implementors make it for them.

So, Henry, if you want to be "portable" and simple, use FILENAME_MAX, and
assume your users will compile it in a standards-compliant environment.  
If you want to be practical and simple, define your own buffer size and
make it a compile-time option.  Tell users about the program limitations.
Don't forget to use character-oriented buffer input routines to avoid
buffer overflows, because actual input may exceed your buffer size. (Even
if you don't get someone trying to cause a security problem, legitimate
filenames may exceed whatever buffer size you use, including
FILENAME_MAX).  If you really want to do it right, dynamically resize the
buffer as you read the filename in (but watch out for heap fragmentation
if you do very much of this).

Perl must be looking pretty good about now. :)

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
Work:<JeffN@endecon.com>              Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k
---------------------------------------------------------------------------




LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
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:
O'Reilly and Associates
For numerous book donations.