apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Justin Erenkrantz" <jus...@erenkrantz.com>
Subject Re: svn commit: r422157 - /apr/apr/trunk/file_io/win32/filepath.c
Date Mon, 17 Jul 2006 15:55:45 GMT
On 7/17/06, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> Justin Erenkrantz wrote:
> >
> > The problem is that the APR code relies on the MSVC run-time being
> > consistent: as we have demonstrated, it's not.  It can and does report
> > c:\ in several circumstances.
> Yes, and so what?  This should be harmless... please indicate the bug
> that the VETOED code supposedly corrects?
> (And Mr. Committer, revert your vetoed code already.)

Why the rush to revert?  We're trying to understand the codebase here
to ensure we're making the right change rather than rushing to revert:
the testcases indicate a clearly false assumption in the APR runtime -
that drive letters are always upper-cased by the runtime.

> > Note that all APR was doing was
> > toupper() which doesn't handle Unicode either.
> No need.  Drive LETTERS aren't full unicode, the drive letter is ascii.

Then why bring up Unicode at all?

> > Again, these are the testnames tests that were failing.
> Cite them.

As Paul said, the testnames cases fail.  I believe the specific test
case is  root_from_cwd_and_back().  apr_filepath_get and
apr_filepath_root are assumed to be identity, but they are not under
APR and Win32.  MSVC runtime reports c:\ via apr_filepath_get(), but
APR upcases that to C:\ when TRUENAME is set.  Hence, c != C.  That is
the root of the incorrect behavior and what's fixed in 422157.

> > Win32 reports c:\ and APR expects it to be C:\.   So, the tests fail.
> Test(s) plural?  Cite them.

I think there are more assumptions in Win32 testnames that rely upon
the identity functions working - so they have to be fixed up too.  In
short, testnames would need to be written to be drive-letter
case-insensitive on Win32.  -- justin

View raw message