"noreturn" attribute in lua_error & Co

[Patrick Rapin <toupie300@...>]

In Lua 5.2, there is a definition for 'l_noret' which is as follows:

#if defined(__GNUC__)
#define l_noret		void __attribute__((noreturn))
#elif defined(_MSC_VER)
#define l_noret		void __declspec(noreturn)
#else
#define l_noret		void
#endif

The macro is used to mark some functions as never returning, typically
because they always throw an error.
GCC and MSVC compilers can use this as an optimizing hint and as a way
to suppress some irrelevant warnings.

My first question is: why don't public API functions also use that attribute ?
Those external functions could be declared as 'noreturn':

LUA_API int   (lua_error) (lua_State *L);
LUALIB_API int (luaL_argerror) (lua_State *L, int numarg, const char *extramsg);
LUALIB_API int (luaL_error) (lua_State *L, const char *fmt, ...);

I may have an answer: maybe it is because they return a dummy 'int' value.
And Microsoft compiler issue a warning when '__declspec(noreturn)' is
used on a function returning something else than 'void'.
Converting those 3 functions to 'l_noret' result in an important
number of changes (see the annexed patch [1]), because in a number of
places there is the idiom : 'return lua_error(L);' or similar. From
some Googling, I noticed that a number of Lua bindings use this idiom
too.

A second question arises: is there any benefit to write 'return
lua_error(L)' instead of just 'lua_error(L)' ? Is this the reason why
lua_error returns an 'int' instead of 'void' ?

[1] A small compilation test show a slight decrease in the executable
size (512 bytes) when the patch is applied.
Not very compelling, but still an argument for such a move in Lua 5.2.1...

Attachment: lua-5.2.0-noret.patch.gz
Description: GNU Zip compressed data