wposix.h File Reference

Go to the source code of this file.

Macros
#define	M_PI   3.14159265358979323846
#define	M_PI_2   1.57079632679489661923
#define	INFINITY   (std::numeric_limits<float>::infinity())
#define	NAN   (std::numeric_limits<float>::quiet_NaN())

Functions
LIB_API int	setenv (const char *envname, const char *envval, int overwrite)
	rationale: the Windows headers declare many POSIX functions (e.g. More...

Macro Definition Documentation

#define INFINITY   (std::numeric_limits<float>::infinity())

Definition at line 70 of file wposix.h.

#define M_PI   3.14159265358979323846

Definition at line 64 of file wposix.h.

#define M_PI_2   1.57079632679489661923

Definition at line 67 of file wposix.h.

#define NAN   (std::numeric_limits<float>::quiet_NaN())

Definition at line 73 of file wposix.h.

Function Documentation

LIB_API int setenv	(	const char *	envname,
		const char *	envval,
		int	overwrite
	)

rationale: the Windows headers declare many POSIX functions (e.g.

read). unfortunately, these are often slightly incorrect (size_t vs. size_t). to avert trouble in user code caused by these differences, we declare all functions ourselves according to SUSv3 and do not use the headers.

however, it does not end there. some other libraries (e.g. wxWidgets) will want to pull in these headers, which would conflict with our declarations. also, our implementation uses the actual CRT code, so we want those functions (e.g. _read) to be declared correctly even if switching compiler/CRT version.

how can these conflicting requirements be reconciled? our headers #include "no_crt_posix.h" to #define the CRT headers' include guards and thus prevent them from declaring anything. the implementation files #include "crt_posix.h", which pulls in the CRT headers (even if "no_crt_posix.h" was previously included, e.g. in the PCH). note that the CRT headers would still cause conflicts with the POSIX function declarations, but we are able to prevent this via STDC.

Definition at line 34 of file wposix.cpp.