Is there an equivalent to WinAPI’s MAX_PATH under linux/unix?

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?

Under windows , we frequently use event to coordinate threads, under java, is there any equivalent mechanism?

Under windows , we frequently use event to synchronize threads. Under java, is there anything equivalent?

Xcode’s NSlog equivalent under Visual Studio

Under Xcode for MAC, I use NSlog and the Console for debugging. Is there an equivalent method under Visual Studio under Windows? Edit: For completeness, here is what needed using System.Diagnostics; /

_wfopen equivalent under Mac OS X

I’m looking to the equivalent of Windows _wfopen() under Mac OS X. Any idea? I need this in order to port a Windows library that uses wchar* for its File interface. As this is intended to be a cross-p

Is there an equivalent to git gui for mercurial under ubuntu?

Is there an equivalent to git gui for mercurial under ubuntu?

What is the equivalent to xargs -r under OsX

Are they any equivalent under OSX to the xargs -r under Linux ? I’m trying to find a way to interupt a pipe if there’s no data. For instance imagine you do the following: touch test cat test | xargs

Prove 2 formulas equivalent under some conditions?

Two formulas a1 == a + b and a1 == b are equivalent if a == 0. I want to find this required condition (a == 0) with Z3 python. I wrote the code below: from z3 import * def equivalence(F, G): s = Solve

Equivalent to “SIGINT” (posix) signal for catching “CTRL+C” under Windows/MinGW

I am porting a Linux/gcc program under windows and implemented common exceptions handling for both. I was wondering what would be the equivalent of SIGINT signal for MinGW/gcc. Here is how I handle it

Reliable way to count running instances of a process on Windows using c++/WinAPIs

I need to know how many instances of my process are running on a local Windows system. I need to be able to do it using C++/MFC/WinAPIs. So what is a reliable method to do this? I was thinking to use

AF_PACKET equivalent under Mac OS X (Darwin)

I am trying to compile a C program on Mac OS X that uses AF_PACKET sockets and libpcap, what is the equivalent in OS X?

What is the C++ equivalent for AutoResetEvent under Linux?

The description of AutoResetEvent in MSDN I’m trying to port a Thread Pool implemented in C# to C++ under Linux. I don’t know which functions I should use that have similar behaviors to AutoResetEven

Answers

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

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

There is a PATH_MAX but it is a bit problematic. According to ‘man realpath’ description:

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

The other answers so far all seem right on point about the *nix side of things, but I’ll add a warning about it on Windows.

You’ve been lied to (by omission) by the documentation.

MAX_PATH is indeed defined, and probably even applies to files stored on FAT or FAT32. However, any path name can be prefixed by //?/ to tell the Windows API to ignore MAX_PATH and let the file system driver make up its own mind. After that, the definitions get fuzzy.

Add to the mix the fact that path names are actually Unicode (well, UTS-16) and that when the “ANSI” API is used the conversion to and from the internal Unicode name is dependent on a bunch of factors including the current code page, and you have a recipe for confusion.

A good description of the rules for Windows is at MSDN. The rules are much more complicated than I’ve summarized here.

Edit: I changed //./ to //?/ in the above thanks to the comment from KitsuneYMG.

Windows paths and namespaces are complicated. Some might even argue they are too complicated. One source of complexity is that the Win32 (and now Win64) API is a subsystem that lays on top of the Windows NT native system.

A path without any prefix is compatible across the widest range of Windows platforms. If it is restricted to 7-bit ASCII characters, then it is compatible with 16-bit DOS since version 2.0 or so (whenever subdirectories were introduced, which might actually have been in DOS 3; but DOS 1.0 only had root directories and the / character had no special meaning).

The //?/ prefix causes the balance of the path name to be passed on verbatim to the appropriate file system driver, which is what produces the effect of dropping the restriction to MAX_PATH characters. If the long path name is also on a network share, then you can use an extended UNC name for it with the prefix //?/UNC/server/share/ instead of the normal UNC name //server/share/. Using this prefix restricts portability to Win32 and later Windows platforms, but unless you require support for 16-bit Windows on legacy hardware, that isn’t a big issue.

The //./ prefix is a different animal. It allows access to device objects beyond the set of specially named devices that are automatically mapped by Windows as special file names into every file folder. Those special names include CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Note that all of those names are special whether or not an extension is used, or in any mix of upper or lower case. But it is possible that you have 10 or more COM ports installed. This happens quickly if you play with USB modems, or USB serial port adapters, since each unique USB-based serial port will be assigned a distinct COMn name. If you need to access the 50th serial port, then you can only do so with the name //./COM50 because COM50 is not a special name like COM1 is.

The MSDN page I cited above had the distinction right, I simply typed the incorrect prefix in my original answer.

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

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


Is there an equivalent to WinAPI’s MAX_PATH under linux/unix?

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?

Under windows , we frequently use event to coordinate threads, under java, is there any equivalent mechanism?

Under windows , we frequently use event to synchronize threads. Under java, is there anything equivalent?

Xcode’s NSlog equivalent under Visual Studio

Under Xcode for MAC, I use NSlog and the Console for debugging. Is there an equivalent method under Visual Studio under Windows? Edit: For completeness, here is what needed using System.Diagnostics; /

_wfopen equivalent under Mac OS X

I’m looking to the equivalent of Windows _wfopen() under Mac OS X. Any idea? I need this in order to port a Windows library that uses wchar* for its File interface. As this is intended to be a cross-p

Is there an equivalent to git gui for mercurial under ubuntu?

Is there an equivalent to git gui for mercurial under ubuntu?

What is the equivalent to xargs -r under OsX

Are they any equivalent under OSX to the xargs -r under Linux ? I’m trying to find a way to interupt a pipe if there’s no data. For instance imagine you do the following: touch test cat test | xargs

Prove 2 formulas equivalent under some conditions?

Two formulas a1 == a + b and a1 == b are equivalent if a == 0. I want to find this required condition (a == 0) with Z3 python. I wrote the code below: from z3 import * def equivalence(F, G): s = Solve

Equivalent to “SIGINT” (posix) signal for catching “CTRL+C” under Windows/MinGW

I am porting a Linux/gcc program under windows and implemented common exceptions handling for both. I was wondering what would be the equivalent of SIGINT signal for MinGW/gcc. Here is how I handle it

Reliable way to count running instances of a process on Windows using c++/WinAPIs

I need to know how many instances of my process are running on a local Windows system. I need to be able to do it using C++/MFC/WinAPIs. So what is a reliable method to do this? I was thinking to use

AF_PACKET equivalent under Mac OS X (Darwin)

I am trying to compile a C program on Mac OS X that uses AF_PACKET sockets and libpcap, what is the equivalent in OS X?

What is the C++ equivalent for AutoResetEvent under Linux?

The description of AutoResetEvent in MSDN I’m trying to port a Thread Pool implemented in C# to C++ under Linux. I don’t know which functions I should use that have similar behaviors to AutoResetEven

Answers

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

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

There is a PATH_MAX but it is a bit problematic. According to ‘man realpath’ description:

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

The other answers so far all seem right on point about the *nix side of things, but I’ll add a warning about it on Windows.

You’ve been lied to (by omission) by the documentation.

MAX_PATH is indeed defined, and probably even applies to files stored on FAT or FAT32. However, any path name can be prefixed by //?/ to tell the Windows API to ignore MAX_PATH and let the file system driver make up its own mind. After that, the definitions get fuzzy.

Add to the mix the fact that path names are actually Unicode (well, UTS-16) and that when the “ANSI” API is used the conversion to and from the internal Unicode name is dependent on a bunch of factors including the current code page, and you have a recipe for confusion.

A good description of the rules for Windows is at MSDN. The rules are much more complicated than I’ve summarized here.

Edit: I changed //./ to //?/ in the above thanks to the comment from KitsuneYMG.

Windows paths and namespaces are complicated. Some might even argue they are too complicated. One source of complexity is that the Win32 (and now Win64) API is a subsystem that lays on top of the Windows NT native system.

A path without any prefix is compatible across the widest range of Windows platforms. If it is restricted to 7-bit ASCII characters, then it is compatible with 16-bit DOS since version 2.0 or so (whenever subdirectories were introduced, which might actually have been in DOS 3; but DOS 1.0 only had root directories and the / character had no special meaning).

The //?/ prefix causes the balance of the path name to be passed on verbatim to the appropriate file system driver, which is what produces the effect of dropping the restriction to MAX_PATH characters. If the long path name is also on a network share, then you can use an extended UNC name for it with the prefix //?/UNC/server/share/ instead of the normal UNC name //server/share/. Using this prefix restricts portability to Win32 and later Windows platforms, but unless you require support for 16-bit Windows on legacy hardware, that isn’t a big issue.

The //./ prefix is a different animal. It allows access to device objects beyond the set of specially named devices that are automatically mapped by Windows as special file names into every file folder. Those special names include CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Note that all of those names are special whether or not an extension is used, or in any mix of upper or lower case. But it is possible that you have 10 or more COM ports installed. This happens quickly if you play with USB modems, or USB serial port adapters, since each unique USB-based serial port will be assigned a distinct COMn name. If you need to access the 50th serial port, then you can only do so with the name //./COM50 because COM50 is not a special name like COM1 is.

The MSDN page I cited above had the distinction right, I simply typed the incorrect prefix in my original answer.

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

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