Am 07.07.2010 22:35, schrieb sturlamolden:
> On 7 Jul, 22:26, Christian Heimes <li...@cheimes.de> wrote:
>
>> Don't forget errno! Every CRT might have its own errno thread local. I
>> don't know how its handled on Windows but I suspect it suffers from the
>> same problem.
>
> The Windows API "errno" is GetLastError. But a delinquent CRT might
> map GetLastError() to other integers.
Please check the source before posting. msvcrt defines errno as
_CRTIMP extern int * __cdecl _errno(void);
#define errno (*_errno())
where _errno is (see dosmap.c)
int * __cdecl _errno(void)
{
_ptiddata ptd = _getptd_noexit();
if (!ptd) {
return &ErrnoNoMem;
} else {
return ( &ptd->_terrno );
}
}
where _getptd_noexit returns the CRT's per-thread data (see tidtable.c).
So it *is* a mapping to other integers, and, even though it's called
dosmap.c, it is maintained because of the (limited) POSIX support in the
CRT. In particular, there is a mapping between GetLastError values and
errno values that can't be implemented through simple defines
(e.g. both ERROR_FILE_NOT_FOUND and ERROR_PATH_NOT_FOUND map to ENOENT).
In addition, a standard C implementation can rely on only certain APIs
changing errno, which MS perhaps might not be able to guarantee for
GetLastError values in exactly the same manner.
So with the way the Windows API is defined, a C implementation has no
alternative but to be delinquent.
Regards,
Martin
|
