[Zlib-devel] zlib 1.2.3.4 Winter Solstice Edition

[Pedro Alves]

On Tuesday 29 December 2009 16:58:59, Cosmin Truta wrote:
> On Tue, Dec 29, 2009 at 10:58 AM, Pedro Alves wrote:
> 
> > _WIN32_WCE isn't the best predicate there is to check
> > for CE (this particular case is about a C runtime issue, not
> > an Win32 API issue, although MSFT's headers don't make much
> > of a distinction; mingw32ce does have such a distinction, just
> > like it's big brother MinGW --- mingw vs w32api), but it's
> > good enough.
> 
> That's why I was suggesting to check for _WIN32_WCE && _MSC_VER.
> You're not checking WinCE (the platform), but Visual C++ (the
> compiler) under WinCE.

Actually, the proper check would be a feature check, not a
version/compiler check.  That is, check if stddef.h is present,
and if it defines ptrdiff_t in an autoconf-style test, and provide
a fallback if not, but I'm too new to zlib and to this list to
seriously propose such a thing.  (/me ducks) :-)  Since MSFT's
runtime and headers are cripled, it's quite common that people
come up with porting-aid libraries, providing the missing bits
and headers, so it's quite likely to find projects around the
web that have imported zlib into their sources and whose build
system makes it so that the replacement and fill-the-gap headers
(stddef.h in this case) are available, even when building
with the Visual C++ compiler (e.g., celib).  But, that's not
upstream zlib's problem, so I think that checking for the
compiler that usually is used with the cripled headers is
a good approximation.  (It would also be possible to
come up with a gcc port that only used MSFT's headers, although
stddef.h is a special case, in that it is always provided by gcc,
and the headers would be fixincluded to sanity first by gcc too).

> 
> > UNDER_CE would be slightly better, as it would
> > avoid having to define _WIN32_WCE in CFLAGS.
> 
> You shouldn't need to add anything to CFLAGS. The macro _WIN32_WCE is
> defined by default under VC++, and it should be defined by default on
> all WinCE compilers, just as _WIN32 should be defined by default on
> all Win32 compilers. 

No, it's not defined by default on all WinCE _compilers_.  When
you create a CE project in Visual Studio, the project settings
conveniently also include a _WIN32_WCE=$(CEVER) in the
Preprocessor Definitions for you.  This is the equivalent of
setting it in CFLAGS.  It is not a builtin, it is not predefined
by the compiler.

_WIN32_WCE is more closely related to _WIN32_WINNT and WINVER than
to _WIN32.  It is an input specifier to the Win32 API headers.
You can define it in a module before including any Win32 API
headers to select the minimum version of the targetted API
you want.  E.g.:

 #define _WIN32_WCE 0x400
 #include <windows.h>

_WIN32 is a builtin compiler define.

However, on mingw32ce/w32api, if you don't define _WIN32_WCE
to anything, the w32api headers default to defining it to 
a reasonably low CE version, 0x300, IIRC.  This is exactly
the same as big brother Desktop MinGW: it defaults
_WIN32_WINNT to 0x400 if it isn't defined already.

> Is this not the case with cegcc? 

It is not.  UNDER_CE is also defined by the project settings on
Visual Studio, but _is_ a builtin define on mingw32ce/cegcc.

-- 
Pedro Alves