On Fri, Dec 24, 2004 at 11:31:23PM +0800, Dmitry Timoshkov wrote:
The situation with fpos_t is even worse. Both VC++ (Win32) and Platform SDK (Win64 part) define it as follows (stdio.h):
#ifndef _FPOS_T_DEFINED #undef _FPOSOFF
#if defined (_POSIX_) typedef long fpos_t; #define _FPOSOFF(fp) ((long)(fp)) #else /* _POSIX_ */
#if !__STDC__ && _INTEGRAL_MAX_BITS >= 64 typedef __int64 fpos_t; #define _FPOSOFF(fp) ((long)(fp)) #else typedef struct fpos_t { unsigned int lopart; int hipart; } fpos_t; #define _FPOSOFF(fp) ((long)(fp).lopart) #endif #endif /* _POSIX_ */
#define _FPOS_T_DEFINED #endif
Oh joy... The question now is what does the 'default' MSVCRT.DLL expect as type for the 'fpos_t' type ? I suppose I will do some tests for that.
As I need anyway to send a new patch (this one make the 'test' directory not compile as my patch to 'stdio.h' does not compile), what should I do for this type ? The chicken way out would be to just change the internal type to be aligned with what we think the native MSVCRT.DLL does and not change the external type but that would not be the best for Winelib applications using MSVCRT (does that exist or do they use the C library) ?
Lionel