apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From makl <abcdefghijklmn...@gmx.net>
Subject Re: [PATCH] Compile APR (HEAD) with MinGW
Date Sat, 01 May 2004 18:05:01 GMT
William A. Rowe, Jr. wrote:

> At 03:05 AM 5/1/2004, makl wrote:
>>* misc/win32/internal.c
>>  Commented out due to issues with _malloc_dbg.
> That's the wrong solution - I already explained on an earlier note.
> Use some sort of #ifdef exclusion instead.

I haven't tried it yet. But if the documentation in the files is correct
it will not work. Both compilers use the same runtime.

>>+++ build.conf  1 May 2004 06:28:17 -0000
>>+# Additional files for the win32 build
>>+win32_extra =
>>+  file_io/unix/copy.lo
>>+  file_io/unix/fileacc.lo
>>+  file_io/unix/filepath_util.lo
>>+  file_io/unix/fullrw.lo
>>+  file_io/unix/mktemp.lo
>>+  file_io/unix/tempdir.lo
> Problem - you've now wrapped the ntos kernel with the posix api, inside
> of apr.  This has caused, and will cause security issues that are pretty
> well documented on bugtraq.  You don't handle win32 filename reserved 
> characters or case insensitivity at all.
> I'd be much happier seeing the win32 api, and while we are at it, perhaps
> we pass the POSIX flag to the win32 CreateFile and other api's to ensure
> the filename handling is case sensitive?  (I'm guessing you want the
> strict filename handling of unix?)

I use the same files as the Windows build (look at libapr.dsp). If there 
  are any problems you should try to fix them there. :)

> As an academic exercise your proposed patch is great - but we need to
> evaluate if wraping apr -> mingw -> posix -> win32 isn't going to create
> more security/bug/interop issues than it solves.

MinGW produce a native WIN32 DLL with the same runtime as VC++ 6.0. So 
there should be the same problems as with the MSVC build. No more and
not less.

View raw message