Re: make pg_attribute_noreturn() work for msvc? - Mailing list pgsql-hackers

Hi,

On 2019-11-12 17:22:05 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2019-11-12 15:58:07 -0500, Tom Lane wrote:
> > I'm a bit confused as to why pg_upgrade.h doesn't use 'extern' for
> > function declarations? Not that it's really related, except for the
> > 'extern' otherwise hiding the effect of pgindent not liking 'void
> > pg_noreturn'…
> 
> There are various headers where people have tended to not use "extern".
> I always disliked that, thinking it was not per project style, but
> never bothered to force the issue.  If we went around and inserted
> extern in these places, it wouldn't bother me any.



> > I don't see a reason not to go for 'pg_noreturn void'?
> 
> That seems kind of ugly from here.  Not sure why, but at least to
> my mind that's a surprising ordering.

Oh, to me it seemed a quite reasonable order. It think it feels that way
to me because we put properties like 'static', 'extern', 'inline' etc
also before the return type (and it's similar for variable declarations
too).

It's maybe also worthwhile to note that emacs parses 'pg_noreturn void'
correctly, but gets confused by 'void pg_noreturn'. It's just syntax
highlighting though, so whatever.


> >> One idea is to merge it with the "void" result type that such
> >> a function would presumably have, along the lines of
> >> #define pg_noreturn    void __declspec(noreturn)
> 
> > Yea, that'd be an alternative. But since not necessary, I'd not go
> > there?
> 
> I kind of liked that idea, too bad you don't.

I don't actively dislike it. It just seemed a bit more magic than
necessary. One need not understand what pg_noreturn does - not that it's
hard to infer from the name - to know the return type of the function.


> One argument for it is that then there'd be exactly one right way to
> do it, not two.  Also, if we find out that there's some compiler
> that's pickier about where to place the annotation, we'd have a
> central place to handle it.

The former seems like a good argument to me. I'm not quite sure I think
the second is likely.


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)

I *think* the standard prescribes _Noreturn to be before the return type
(it's defined in the same rule as inline), but I have some difficulty
parsing the standard language. Gcc at least accepts inline only before
the return type, but _Noreturn in both places.

Certainly all the standard examples place it before the type.


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.


Greetings,

Andres Freund