Is there an equivalent to WinAPI's MAX_PATH un

2019-01-10 09:50发布

If I want to allocate a char array (in C) that is guaranteed to be large enough to hold any valid absolute path+filename, how big does it need to be.

On Win32, there is the MAX_PATH define. What is the equivalent for Unix/linux?

7条回答
放荡不羁爱自由
2楼-- · 2019-01-10 09:57

Well, on Linux at least, there is:

  • PATH_MAX (defined in limits.h)

  • FILENAME_MAX (defined in stdio.h)

both of these are set to 4096 on my system (x86 Linux).

Update: : Some info from the glibc manual on this

Each of the following macros is defined in limits.h only if the system has a fixed, uniform limit for the parameter in question. If the system allows different file systems or files to have different limits, then the macro is undefined; use pathconf or fpathconf to find out the limit that applies to a particular file

查看更多
不美不萌又怎样
3楼-- · 2019-01-10 10:03

You can use pathconf() to figure out at run-time, but there's also a PATH_MAX preprocessor define in <limits.h>.

查看更多
Viruses.
4楼-- · 2019-01-10 10:06

limits.h

/*
 * File system limits
 *
 * NOTE: Apparently the actual size of PATH_MAX is 260, but a space is
 *       required for the NUL. TODO: Test?
 * NOTE: PATH_MAX is the POSIX equivalent for Microsoft's MAX_PATH; the two
 *       are semantically identical, with a limit of 259 characters for the
 *       path name, plus one for a terminating NUL, for a total of 260.
 */
#define PATH_MAX    260

minwindef.h

#define MAX_PATH 260
查看更多
▲ chillily
5楼-- · 2019-01-10 10:08

FILENAME_MAX is part of the ISO C standard, it works on UNIX and Windows. However, the GNU C library documentation contains the following warnings:

"Unlike PATH_MAX, this macro is defined even if there is no actual limit imposed. In such a case, its value is typically a very large number. This is always the case on the GNU system.

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."

查看更多
再贱就再见
6楼-- · 2019-01-10 10:08

You can use the realpath function to allocate a buffer big enough for a specific path. If you pass it a null pointer as the 2nd argument it will allocate a buffer big enough for the path. The man page probably explains it better than I can:

realpath() expands all symbolic links and resolves references to /./, /../ and extra '/' characters in the null-terminated string named by path to produce a canonicalized absolute pathname. The resulting pathname is stored as a null-terminated string, up to a maximum of PATH_MAX bytes, in the buffer pointed to by resolved_path. The resulting path will have no symbolic link, /./ or /../ components.

If resolved_path is specified as NULL, then realpath() uses malloc(3) to allocate a buffer of up to PATH_MAX bytes to hold the resolved pathname, and returns a pointer to this buffer. The caller should deallocate this buffer using free(3).

http://linux.die.net/man/3/realpath

查看更多
Explosion°爆炸
7楼-- · 2019-01-10 10:13

There is a PATH_MAX, but it is a bit problematic. From the bugs section of the realpath(3) man page:

The POSIX.1-2001 standard version of this function is broken by design, since it is impossible to determine a suitable size for the output buffer, resolved_path. According to POSIX.1-2001 a buffer of size PATH_MAX suffices, but PATH_MAX need not be a defined constant, and may have to be obtained using pathconf(3). And asking pathconf(3) does not really help, since, on the one hand POSIX warns that the result of pathconf(3) may be huge and unsuitable for mallocing memory, and on the other hand pathconf(3) may return -1 to signify that PATH_MAXis not bounded.

查看更多
登录 后发表回答