bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Error handling in Win32 + gnulib


From: Bruno Haible
Subject: Re: Error handling in Win32 + gnulib
Date: Mon, 30 Nov 2009 22:20:19 +0100
User-agent: KMail/1.9.9

Richard W.M. Jones wrote:
> | Software using gnulib should use errno exclusively, along with
> | standard Unix functions such as perror, strerror, etc., which Gnulib
> | may replace as necessary so these functions work correctly on
> | platforms that lack them (ie. Win32).  All Gnulib POSIX replacement
> | functions will set errno in the case of error according to POSIX
> | requirements, even on underlying platforms that don't do this
> | (ie. Win32).

This is the goal, yes. But there are certain functions for which it is
known that native Windows implementation does not set errno, and yet
gnulib does not fix this behaviour. For example:
doc/posix-functions/fgetc.texi

  Portability problems not fixed by Gnulib:
  @itemize
  @item
  On Windows platforms (excluding Cygwin), this function does not set 
@code{errno}
  upon failure.
  @end itemize

There is plenty of room for future work.

> My take from this is that we need a 'set_errno' function which is
> equivalent to 'set_winsock_errno' and is used for all non-socket
> functions.  It would do:
> 
>   void
>   set_errno (void)
>   {
>     DWORD err = GetLastError ();
>     switch (err) {
>       case ERROR_INVALID_ACCESS:
>         errno = EFAULT;
>         break;
>       case ERROR_OUTOFMEMORY:
>         errno = ENOMEM;
>       break;
>       /* etc for another 1000 or so errors */
>     }
>   }
> 
> 'set_errno' should be called on the error path in most Gnulib
> replacement functions, where the underlying function that Gnulib is
> calling could be a Win32 function.

Yes, it looks like the semantics of Win32 errors and POSIX errors are
similar enough in general, that such a function is useful. There may be
a few special cases where the values need to be mapped differently,
but such a function would be useful to catch all kinds of undocumented
Win32 errors.

The name is suboptimal; maybe call it convert_lasterror_to_errno (), or
similar?

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]