Re: [PATCH] file-name.c and MinGW paths.

[Ben Pfaff]

"John McCabe-Dansted" <address@hidden> 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