Possible Windows Build Bug

[Zachary Greve]

It happens when building list files for AES, DSA, and so on. Which one it crashes on is different each time.

I am going to try building again and see what I get.

> Date: Mon, 22 Jun 2015 17:27:56 -0400
> From: kaduk at MIT.EDU
> To: ztgreve at live.com
> CC: kerberos at MIT.EDU
> Subject: Re: Possible Windows Build Bug
> 
> On Mon, 22 Jun 2015, Zachary Greve wrote:
> 
> > In the echo_files method in the libecho utility there is a line that reads:
> >
> > ff = _findfirst(f, &fdt); // line 64
> >
> > which errors out with an access violation in ntdll.dll.
> 
> Can you say a bit more about where this crash is observed?  E.g., during a
> build of what version of the krb5 tree (where in the build?), using which
> compiler and windows SDK version, etc..
> 
> > Changing the line to read:
> >
> > ff = _findfirst(filepath, &fdt);
> >
> > fixed the issue.
> >
> > Is this a bug?
> 
> This piece of code is (very old and) written in a rather strange way, but
> I am not convinced that your propsal is a correct fix to the bug, if one
> is present.
> 
> The purpose of this utility is to expand wildcards in a given path
> expression (it is only used in two makefiles in the tree).  There seems to
> be an implicit assumption that the wildcard will only occur in the last
> path component.  The _find() family returns only the matched filename
> (without directory), so libecho requires a copy of the containing
> directory as well as the full path (i.e., wildcard expression) in order to
> fulfil its purpose of printing out all matches to the wildcard.  The
> directory is stored in the 'filepath' variable, whereas the wildcard
> expression is in 'f'.  So, I think the _findfirst() call should use f, not
> filepath.
> 
> I think we need to hear more about the crash and the context of the failed
> call in order to say what's going on here.
> 
> -Ben Kaduk
> 
> P.S. kfwdev@ might be a better list to discuss this on.
>