lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] [PATCH] Use "noreturn" attribute in the function declaration t


From: Vadim Zeitlin
Subject: Re: [lmi] [PATCH] Use "noreturn" attribute in the function declaration too
Date: Wed, 15 Mar 2017 13:53:59 +0100

On Wed, 15 Mar 2017 09:24:01 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-03-15 00:12, Vadim Zeitlin wrote:
GC> > 
GC> >  As previously mentioned, my reading of the Standard seems to indicate 
that
GC> > not using the "noreturn" attribute in the function declaration, but using
GC> > it in the function definition makes the program ill-formed. Whether I'm
GC> > correct or not, it definitely makes it uncompilable with MSVC which gives
GC> > many errors similar to the following one:
GC> 
GC> [split into several lines]
GC> 
GC> > any_member.hpp(572): error C2381: \
GC>   'MemberSymbolTable<ClassType>::complain_that_no_such_member_is_ascribed': 
redefinition; \
GC>   '__declspec(noreturn)' or '[[noreturn]]' differs (compiling source file 
gpt_input.cpp)
GC> > 
GC> >  The attached patch simply adds "[[noreturn]]" to the function 
declaration,
GC> > which seems like the right fix to me. Could you please apply it?
GC> 
GC> Please try my commit 082dd93 instead and let me know whether it works
GC> (once I push it; I want to consider your other, later patch first).

 I don't know yet what this commit does, of course, but if it removes
[[noreturn]] from complain_that_no_such_member_is_ascribed() definition,
then I can confirm that it works (well, compiles) with MSVC just fine.

GC> I agree that it was wrong to write [[noreturn]] on the definition but
GC> not on the declaration.
...
GC> However, your patch seems to suggest that, following a declaration that
GC> specifies [[noreturn]], the definition of the same function may specify
GC> it too.

 I think it "may", even though it doesn't have to.

GC> Reading between the lines of the standard, I think it's allowed
GC> only on declarations. I.e., I think the word "may" in the first sentence
GC> quoted above is exclusive: the standard doesn't grant permission for this
GC> attribute to be used in any other situation than a function declaration.

 I agree with this, but I think that a definition counts as a declaration
too and so the attribute is allowed in it even if, again, not required.

 Practically speaking, all the 3 major compilers accept both the presence
and absence of the attribute in the definition, but only g++ accepts its
absence in the declaration, in addition to MSVC error shown above, I can
also give the clang one:

        % cat -n noret.cpp
             1  void func();
             2
             3  [[noreturn]] void func()
             4  {
             5      throw 17;
             6  }
        % clang++-4.0 -std=c++11 -Wall -fsyntax-only -c noret.cpp
        noret.cpp:3:3: error: function declared '[[noreturn]]' after its first 
declaration
        [[noreturn]] void func()
          ^
        noret.cpp:1:6: note: declaration missing '[[noreturn]]' attribute is 
here
        void func();
             ^
        1 error generated.

 The question of whether to repeat the attribute in the function definition
or omit it seems to be a question of style to me and, personally, I think
omitting it is preferable, but using it is justifiable too because it might
help clarify the function intention when reading its definition.

 Regards,
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]