[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ben Pfaff
Subject: Re: [PATCH] file-name.c and MinGW paths.
Date: Sun, 18 Feb 2007 08:40:54 -0800
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)

"John McCabe-Dansted" <address@hidden> writes:

> In dirname.h:
> # ifndef ISSLASH
> # 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 if the backslash character may also serve as a file name component
   separator. */

/* Define if a drive letter prefix denotes a relative path if it is not
   followed by a file name component separator. */

# define ISSLASH(C) ((C) == '/' || (C) == '\\')
# define ISSLASH(C) ((C) == '/')

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]