Re: [xml] Windows build
- From: "Peter Jacobi" <pj walter-graphtek com>
- To: Igor Zlatkovic <igor stud fh-frankfurt de>, xml gnome org
- Subject: Re: [xml] Windows build
- Date: Wed, 02 Oct 2002 13:38:12 +0200
Hi Igor, All,
Wait... I'm confused. Adding a
#ifdef _MSC_VER
#define __MSVCRT__
#endif
and a
#ifdef __BORLANDC__
#define __MSVCRT__
#endif
few rows earlier produces exactly what you proposed, not true?
No, because it introduces another layer between compilers and features. See
below. And in this concrete case, there are compilers (at least WATCOM),
not using the MS runtime but having the same snprintf issue.
The only
difference to my version is that these two are defined in the makefile, not
in the source. I fear that would force people to use a specific runtime with
a specific compiler.
Your proposal is good and I agree with it. I would just make this
runtime-specific macro an exception to that rule and have it defined outside
libxml code. This __MSVCRT__ does not specify a compiler-feature, it
specifies which runtime is used. In the above example, the availability of
snprintf is a runtime-feature, it has nothing to do with the compiler.
Disagree. The included (or replaced) runtime library is part of the
compiler for purposes of claiming standards conformance. What I mean
with compiler is actually a compiler proper + standard library
implementation and each such combination must declare its feature set.
The __MSCVRT__ switch is an intermediate layer, just as C99 could be, for
simplifying writing the macros:
Compiler Layer:
#ifdef _MSC_VER
#define __MSVCRT__
#define THAT_FEATURE
#endif
#ifdef __BORLANDC__
#define __MSVCRT__
#define THIS_FEATURE
#endif
#ifdef _WATCOM
#define SNPRINTF_NEEDS_UNDERSCORE
#endif
Intermediate Layer:
#ifdef __MSVCRT__
#define SNPRINTF_NEEDS_UNDERSCORE
#define BUNCH_OF_FEATURES_IMPLIED_BY_MSVCRT
#endif
Feature Layer
#define SNPRINTF_NEEDS_UNDERSCORE
#undef snprintf
#define snprintf _snprintf
#endif
Only question is, wether this will make things really easier.
The logic of
including winsock.h or not remains the same.
Great! Thanks.
Regards,
Peter Jacobi
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]