| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bryan Green <dbryan(dot)green(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: C nitpick about pgwin32_dispatch_queued_signals() |
| Date: | 2025-11-02 16:47:45 |
| Message-ID: | 428507.1762102065@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bryan Green <dbryan(dot)green(at)gmail(dot)com> writes:
> On 11/2/2025 7:05 AM, Christian Ullrich wrote:
>> the current MSVC compiler deems it necessary to issue
>> warning C4053: one void operand for '?:'
>> for a line with CHECK_FOR_INTERRUPTS(). This boils down to this bit of
>> miscadmin.h (line 116 in master):
>>
>> #define INTERRUPTS_PENDING_CONDITION() \
>> (unlikely(UNBLOCKED_SIGNAL_QUEUE()) ?
>> pgwin32_dispatch_queued_signals() : 0, \
>> unlikely(InterruptPending))
>> #endif
>>
>> The C spec says that of the possible results of the :? operator, either
>> none or both can be void, and pgwin32_dispatch_queued_signals() is void
>> (and has been as far back as I can find it).
> Yeah, this is a bug, or at least a spec violation. We should fix it in
> my opinion-- it's non-conforming C. Others may disagree, though.
Agreed.
> 2. Restructure to use && instead of ?::
> #define INTERRUPTS_PENDING_CONDITION() \
> (unlikely(UNBLOCKED_SIGNAL_QUEUE()) && \
> (pgwin32_dispatch_queued_signals(), true), \
> unlikely(InterruptPending))
> I'd lean towards #2 --- it's cleaner and avoids the whole issue.
I dunno, don't really like the nested comma operator here.
It's probably necessary to avoid having a void argument to &&,
but it's confusing. Let's go with your #1 (casting the 0 to void).
But can't we simplify that to just
#define INTERRUPTS_PENDING_CONDITION() \
(unlikely(UNBLOCKED_SIGNAL_QUEUE()) ?
pgwin32_dispatch_queued_signals() : (void) 0, \
unlikely(InterruptPending))
#endif
that is, the only change needed is s/0/(void) 0/.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2025-11-02 16:50:24 | Re: C nitpick about pgwin32_dispatch_queued_signals() |
| Previous Message | Tom Lane | 2025-11-02 16:26:06 | Re: Should HashSetOp go away |