[Top][All Lists]

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

Re: Minor patch to correct buffer overrun

From: Chris Sutcliffe
Subject: Re: Minor patch to correct buffer overrun
Date: Mon, 16 Aug 2010 11:13:20 -0400

Hi Paul,

On 16 August 2010 09:32, Paul Smith wrote:
> Are you saying that MinGW defines a MAXPATHLEN that is shorter than the
> real maximum path length on Windows, and that the max path length on
> Windows is really 1024 not 259?  So, this change is a workaround for a
> MinGW system header bug?

No, I didn't explain things well.  MAX_PATH on windows should be 259.

> Or, are you saying that make is using this value incorrectly, and that
> instead of MAXPATHLEN it should be using something else?

Looking at the make source, in particular dir.c, it has (in find_directory()):

        char tem[MAXPATHLEN], *tstart, *tend;

and when running the attached Makefile with make via GDB, make craped
out in the find_directory function.  So based on my findings explained
below, I suspected that MAXPATHLEN was expected to be greater than

> And, I'm not sure what you mean by "make expects 'MAXPATHLEN' to be
> considerably bigger"; in what way does make expect this?  Do you mean
> that in one place make creates a buffer of 1024, and in another place it
> tries to copy it into a buffer that is MAXPATHLEN large?

My debugging process was somewhat convoluted.  Upon discovering that
the original make-3.82 binary I produced for MinGW caused an exception
with the attached Makefile, I re-compiled the binary and did not strip
it (which how I found out about the failure in find_directory()).
Unfortunately doing further debugging with GDB was problematic due to
the optimization (-O2).  I recompiled again without optimization and
did not experience the exception.  Being far from a GDB expert, I was
at a loss as to how to use GDB to debug this issue further (i.e. with
the Optimization enabled).  However, I've seen this type of behaviour
before with pointers addressing memory they shouldn't be.

I was made aware on the MinGW-Users list that when compiled with the
build_w32.bat file, the gnumake.exe produced did not generate the
exception.  Doing a comparison between config.h.W32 and the generated
config.h (via running configure in MSYS), I noticed there were several
differences.  Executing a trial-and-error approach, I found that the
exception occurred if 'HAS_SYS_PARAM_H' was defined.

Looking at MinGW's sys/param.h I saw that MAXPATHLEN was defined as follows:


where PATH_MAX is defined as 259.  Looking at make.h I saw:

# define MAXPATHLEN 1024

Given the behaviour I was experiencing (the exception) and seeing the
discrepancy in MAXPATHLEN, I made the minor change:

#ifdef __MINGW32__
# define MAXPATHLEN 1024

Under the assumption that make was expecting MAXPATHLEN to be 1024
(vs. 259).  When I recompiled with this change, I could no longer
re-create the exception.

Please let me know if there is anything more I can do to help.


Chris Sutcliffe

Attachment: Makefile
Description: Binary data

reply via email to

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