"John McCabe-Dansted" <[EMAIL PROTECTED]> writes: > In dirname.h: > > # ifndef ISSLASH > # define ISSLASH(C) ((C) == DIRECTORY_SEPARATOR) > # endif > > This does not support systems with more than one directory_seperator. > We probably want the ISSLASH from "pathname.h". To use pathname.h, we > have to #include it *before* we #include "dirname.h" (and request it > from gnulib in Smake).
This is what I thought at first, too. Then I took a look at the Autoconf macros that go along with dirname. In fact, on Windows they will cause to be defined, in config.h, the following macros: /* Define on systems for which file names may have a so-called `drive letter' prefix, define this to compute the length of that prefix, including the colon. */ #define FILE_SYSTEM_ACCEPTS_DRIVE_LETTER_PREFIX 1 /* Define if the backslash character may also serve as a file name component separator. */ #define FILE_SYSTEM_BACKSLASH_IS_FILE_NAME_SEPARATOR 1 /* Define if a drive letter prefix denotes a relative path if it is not followed by a file name component separator. */ #define FILE_SYSTEM_DRIVE_PREFIX_CAN_BE_RELATIVE 1 #if FILE_SYSTEM_BACKSLASH_IS_FILE_NAME_SEPARATOR # define ISSLASH(C) ((C) == '/' || (C) == '\\') #else # define ISSLASH(C) ((C) == '/') #endif Thus, dirname.h works at least as well as pathname.h, and in fact (if you look at the m4 macros) it seems to be a little better. The result was that I only needed dirname, and not pathname. >> + char cname[PATH_MAX]; > > I have heard that it is a good habit to avoid arrays on the stack, as > they can be security holes, and can overflow the stack if the array > size is large compared to the stack size on an architecture. > > This is a nit, and obviously the overall programming style in PSPP is > your call. Indeed, I imagine a decision counter to this has already > made, but I thought I'd explain my programming style, just in case it > so happened the issue had never been considered. In this case I'm not worried about it: we know that this code is compiled under Windows, and MinGW defines it as 259. -- "Long noun chains don't automatically imply security." --Bruce Schneier _______________________________________________ pspp-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/pspp-dev
