Re: Extend win32 error codes to errno mapping in win32error.c

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Extend win32 error codes to errno mapping in win32error.c
Date: 2022-09-28 04:40:08
Message-ID: YzPQKCx8Uz0bxGYx@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 27, 2022 at 03:23:04PM +0530, Bharath Rupireddy wrote:
> The failure occurs in dosmaperr() in win32error.c due to an unmapped
> errno for win32 error code. The error code 123 i.e. ERROR_INVALID_NAME
> says "The file name, directory name, or volume label syntax is
> incorrect." [2], the closest errno mapping would be ENOENT. I quickly
> looked around for the other win32 error codes [2] that don't have
> mapping.

> I filtered out some common error codes such as
> ERROR_OUTOFMEMORY, ERROR_HANDLE_DISK_FULL, ERROR_INSUFFICIENT_BUFFER,
> ERROR_NOACCESS. There may be many more, but these seemed common IMO.
>
> Having a right errno mapping always helps recognize the errors correctly.

One important thing, in my opinion, when it comes to updating this
table, is that it could be better to report the original error number
if errno can be somewhat confusing for the mapping. It is also less
interesting to increase the size of the table for errors that cannot
be reached, or related to system calls we don't use.

ERROR_INVALID_NAME => ENOENT
Yeah, this mapping looks fine.

ERROR_HANDLE_DISK_FULL => ENOSPC
This one maps to various Setup*Error(), as well as
GetDiskFreeSpaceEx(). The former is not interesting, but I can buy
the case of the former for extension code (I've played with that in
the past on WIN32, actually).

ERROR_OUTOFMEMORY => ENOMEM
ERROR_NOACCESS => EACCES
ERROR_INSUFFICIENT_BUFFER => EINVAL
Hmm. I have looked at our WIN32 system calls and the upstream docs,
but these do not seem to be reachable in our code.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2022-09-28 04:43:20 Re: Use pg_pwritev_with_retry() instead of write() in dir_open_for_write() to avoid partial writes?
Previous Message Bharath Rupireddy 2022-09-28 04:39:25 Re: Avoid memory leaks during base backups