[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NetCDF & HPUX

> Organization:  National Energy Research Supercomputer Center (NERSC)
> Keywords: 199402081848.AA23753 HPUX ncredef

> 1.
 ...
This problem might be related to the FILENAME_MAX problem.
If the current file name is more than FILENAME_MAX + 1 characters long
(easy when FILENAME_MAX is 14), then the strcpy at line 318 of
libsrc/file.c will fail silently and at best result in an unterminated
string in tnbuf.

Fix FILENAME_MAX and see if this problem persists.

 ...

> Here's HP's response to my message querying them about FILENAME_MAX:
> 
> >You are correct in that FILENAME_MAX is defined to be 14. However, you
> >probably should be using MAXNAMLEN as it is ansi compliant.

I'm not sure what this guy is trying to say.
FILENAME_MAX is a macro which the ANSI spec requires in <stdio.h>
which
" expands to an integral constant expression 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." - 7.9.1

The POSIX spec put further contraints on this as PATH_MAX, it must
be greater than or equal to _POSIX_PATH_MAX which is 255. HP is confused
by setting FILENAME_MAX to _POSIX_NAME_MAX (14) instead. NAME_MAX
is (informally) the maximum length of the "trailing component" of a path.

> >It (MAXNAMELEN) is
> >defined in ndir.h as well as a few other header files.

MAXNAMELEN is not an ANSI C or POSIX constant, and therefor is _NOT_
what we "probably should be using". (netCDF is spec'ed to only "count on"
ANSI C being available.)
Perhaps this service engineer means that MAXNAMELEN has the correct value.

> >If you cannot use
> >another constant, then you may consider creating a user header file to
> >be included with your application that sets FILENAME_MAX to 255.

In any event, the HP value for FILENAME_MAX is wrong, and should be
fixed. You should fix it on your system in <stdio.h>,
and tell HP to fix it in their distributions.

-glenn