From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Antonin Houska <ah(at)cybertec(dot)at> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Return value of PathNameOpenFile() |
Date: | 2022-09-06 07:51:43 |
Message-ID: | 1ECFEFA0-C3F7-450E-9571-EB22202F5B2D@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 6 Sep 2022, at 09:26, Antonin Houska <ah(at)cybertec(dot)at> wrote:
>
> I've noticed that some callers of PathNameOpenFile()
> (e.g. bbsink_server_begin_archive()) consider the call failed even if the
> function returned zero, while other ones do check whether the file descriptor
> is strictly negative. Since the file descriptor is actually returned by the
> open() system call, I assume that zero is a valid result, isn't it?
Agreed, zero should be valid as it's a non-negative integer. However, callers
in fd.c are themselves checking for (fd <= 0) in some cases, and some have done
so since the very early days of the codebase, so I wonder if there historically
used to be a platform which considered 0 an invalid fd?
--
Daniel Gustafsson https://vmware.com/
From | Date | Subject | |
---|---|---|---|
Next Message | houzj.fnst@fujitsu.com | 2022-09-06 07:57:43 | RE: pg_publication_tables show dropped columns |
Previous Message | Zhang Mingli | 2022-09-06 07:50:08 | Re: Remove dead macro exec_subplan_get_plan |