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
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. |