Due to Android (and apparently Sun) not supporting getcwd(NULL, 0), I've changed to call to getcwd to specify a buffer and explicit size which successfully works around the problem. One minor performance advantage is that one less malloc/free is needed since the buffer is now created on the stack. Apparently, this was already changed in a prior commit I didn't see initially, but I think the use of an invented/arbitrary PATH_MAX is incorrect. Platforms should generally provide a constant for this and PATH_MAX itself is already defined on some systems like Linux which can cause collisions. This commit improves on those changes by leveraging the constants provided by the compiler/system.

To help keep the code consistent but still correct, new platform specific code needed to be introduced for the max length. On POSIX I am assuming it is that <sys/param.h> provides MAXPATHLEN. This is what the Mac/BSD man page says to use and verified this is also defined on Ubuntu Linux and Android. On Windows, MAX_PATH is used. MAX_PATH seems to still be 260 which seems kind of small; is there a different constant we are supposed to use? In both cases, the respective constants are mapped to a new #define for LFS_MAXPATHLEN to allow the code to refer to one constant and avoid any potential name collisions in case MAXPATHLEN is defined already by something else on Windows (e.g. Cygwin).

0 files changed, 0 insertions, 0 deletions