apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: #else APR_HAS_UNICODE_FS ???
Date Thu, 06 Oct 2005 18:09:18 GMT
Dan Johnson wrote:
> I’m working on compiling APR with mingw. In 
> include/arch/win32/apr_arch_misc.h there’s the following code starting 
> at line 132:

#if APR_HAS_ANSI_FS && APR_HAS_UNICODE_FS
#define IF_WIN_OS_IS_UNICODE if (apr_os_level >= APR_WIN_UNICODE)
#define ELSE_WIN_OS_IS_ANSI else
#else APR_HAS_UNICODE_FS
#define IF_WIN_OS_IS_UNICODE
#define ELSE_WIN_OS_IS_ANSI
#endif /* WINNT */

> MSVC accepts this code with no complaint, but mingw (rightfully, I 
> think) generates “warning: extra tokens at end of #else directive.” Can 
> someone tell me what this code is supposed to mean?

Confusing, eh?  I believe the #else is correct, and should have read;

#else /* !APR_HAS_UNICODE_FS || !APR_HAS_ANSI_FS */

and that the VC compiler silently ignored this.

First note the case above;

#if defined(_WIN32_WCE) || defined(WINNT)
#define APR_HAS_ANSI_FS           0
#else
#define APR_HAS_ANSI_FS           1
#endif

...which means _WCE and WINNT need -no- ANSI mode at all (and _WCE has
no Win32FnA flavors, only Win32FnW flavors, e.g. Unicode).

On WIN32, we always define APR_HAS_UNICODE_FS - even on Win9x you can
use the high-bit characters as a faux-utf8.

Let's take a simple snippet from proc_mutex.c ...

#if APR_HAS_UNICODE_FS
     IF_WIN_OS_IS_UNICODE
     {
         hMutex = CreateMutexW(NULL, FALSE, mutexkey);
     }
#endif
#if APR_HAS_ANSI_FS
     ELSE_WIN_OS_IS_ANSI
     {
         hMutex = CreateMutexA(NULL, FALSE, mutexkey);
     }
#endif

So once it's exclusively set up with APR_HAS_ANSI_FS or else
APR_HAS_UNICODE_FS, the resulting code is faster and smaller,
but will not be portable between 9x and NT.  Eg., on any build
with APR_HAS_ANSI_FS and not APR_HAS_UNICODE_FS, the code above
devolves to;

     {
         hMutex = CreateMutexA(NULL, FALSE, mutexkey);
     }


If you build ANSI_FS on NT, your build will only be able to handle
filenames and resources that map to the current console-mode codepage.
E.g., a web server with resources in several languages will likely fail.

OTOH, if you build UNICODE_FS on 9x, your calls to Win32FnW will fail.

So from a mingw perpsective, if you want to build to target the actual
OS you are configuring on, you should always -D WIN32 and set -D WINNT
for exclusively NT builds, -D _WIN32_WCE for exclusively Windows CE,
and you can (unlike the Win32 native build) unset APR_HAS_UNICODE_FS
if you are targetting Win9x only.

Hope this helps.

Bill

Mime
View raw message