Re: bug in gcc?

[Sam Roberts <sroberts@...>]

On Wed, Apr 04, 2007 at 09:37:08PM +0100, David Given wrote:
> [1] Notice that 'usually'? This is the reason why x("hi") works. In an
> incredibly brain-damaged fit of, well, something, the C++ designers decided
> that it would be convenient if constant strings could be implicitly cast to
> char*. But this only happens if the constant string is *directly* cast to a
> char*. If you do an operation on it first, the const char* type is used
> instead. So:
> 
> x("hi"); // works.
> x("hi"+1); // fails!

Well, in fairness to the C and C++ folks, I don't think either standard
specified whether a string literal is const or not, and lots of code
assumes they aren't const. Its started to default to const recently with
gnu, IIRC, because it allows linkers to unify all identical string
literals, an optimization that would not be safe if they could be
changed. And Stroustrup (in design and evolution of c++) laments that
there were some things he wanted to be illegal but that were so common
he had to allow them. int to char assignments, for example.

> Besides, can luaL_error() fail?

Doesn't appear so from reading the code, not in lua 5.0 anyhow.

I don't really mind the idiom, though I don't use it myself. Most
non-lua library functions that don't return - abort(), longjmp(), exit()
- return void. C programmers are used to dealing with this, even without
gcc-specific hacks:
  func_that_wont_return();
  return 0;
  
is pretty typical and portable. So is

  if(some error)
	  lua_error();

  ... code when there isn't an error

  return the_return_value;

Sam