Re: make pg_attribute_noreturn() work for msvc?

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: make pg_attribute_noreturn() work for msvc?
Date: 2019-11-12 23:26:39
Message-ID: 20191112232639.lcgcnz6q525zb4to@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2019-11-12 18:15:28 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > It's worthwhile to note - I forgot this - that noreturn actually has
> > been standardized in C11 and C++11. For C11 the keyword is _Noreturn,
> > with a convenience macro 'noreturn' defined in stdnoreturn.h.
>
> > For C++11, the syntax is (please don't get an aneurysm...):
> > [[ noreturn ]] void funcname(params)...
> > (yes, the [[]] are actually part of the syntax, not some BNF like thing)
>
> Egad. I'd *want* to hide that under a macro :-(

Yea, it's quite ugly.

I think the only saving grace is that C++ made that the generic syntax
for various annotations / attributes. Everywhere, not just for function
properties. So there's [[noreturn]], [[fallthrough]], [[nodiscard]],
[[maybe_unused]] etc, and that there is explicit namespacing for vendor
extensions by using [[vendorname::attname]], e.g. the actually existing
[[gnu::always_inline]].

There's probably not that many other forms of syntax one can add to all
the various places, without running into syntax limitations, or various
vendor extensions...

But still.

> > While it looks tempting to just use 'noreturn', and backfill it if the
> > current environment doesn't support it, I think that's a bit too
> > dangerous, because it will tend to break other code like
> > __attribute__((noreturn)) and _declspec(noreturn). As there's plenty
> > other software using either or both of these, I don't think it's worth
> > going there.
>
> Agreed, defining noreturn is too dangerous, it'll have to be
> pg_noreturn. Or maybe use _Noreturn? But that feels ugly too.

Yea, I don't like that all that much. We'd have to define it in C++
mode, and it's in the explicit standard reserved namespace...

> Anyway, I still like the idea of merging the void keyword in with
> that.

Hm. Any other opinions?

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-11-12 23:54:33 Re: checking my understanding of TupleDesc
Previous Message Peter Geoghegan 2019-11-12 23:21:53 Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.