Re: Comprehending string.gsub

[Robert Virding <robert.virding@...>]

Yes, I am re-implementing Lua which is I am asking nit-picky questions like this. Even if something is unspecified it would still be good to behave in the same way as the standard implementation. I know that in some cases things are unspecified but people still use them and "know" how they behave and expect them to behave in a certain manner.

One of my favourite peeves is #table when the table part doesn't consist of a sequence. It still works and returns a value which is indistinguishable from a valid value. And in many case the value is sensible, but not always. I know people shouldn't use like this but they do, and they expect it to behave in the "standard" way.

I come from an environment where not much is unspecified and doing illegal things always results in an error.

Robert

----- Original Message -----
> On Fri, Apr 13, 2012 at 2:33 PM, Roberto Ierusalimschy
> <roberto@inf.puc-rio.br> wrote:
> >>[...] if the behaviour is undefined, why is it in the tests? :)
> > Another non-written rule in Lua is that, even for undefined
> > behavior,
> > the interpreter should not crash. So, the tests must cover
> > undefined
> > cases too.
> >
> > Moreover, Lua uses whitebox testing. Many tests in Lua assume
> > specific
> > behaviors that we know it is true for that specific implementation.
> > (For
> > instance, several tests assume specific wordings for error
> > messages.)
> > This test style allows much more strict tests, which are not
> > possible
> > testing only the specification.
> 
> Those re-implementing Lua may want to take the initiative to rewrite
> the test suite in a form like this:
> 
>   function unspecified(f)
>     if WARN_UNSPECIFIED == 'fail' then
>       f()
>     else
>       local ok, err = pcall(f) -- check that it doesn't crash
>       if WARN_UNSPECIFIED then
>         io.stderr:write('WARN:failure in unspecified:', err, '\n')
>       end
>     end
>   end
>   . . .
>   unspecified(function() assert(string.gsub("abc", "%w", "%1%0") ==
> "aabbcc") end)
> 
> (But I'm not sure if the test suite has a license, so I suggest
> checking if it's ok to release a modified test suite.)
> 
> This also reminds me of the idea [1] of writing a wrapper around the
> "_G" library so that it warns or fails upon hitting unspecified
> behavior.  Incidentally, that would be one way to test the test suite
> concerning unspecified behavior.
> 
> [1] http://lua-users.org/lists/lua-l/2012-03/msg00936.html
> 
> 
> On Fri, Apr 13, 2012 at 12:16 PM, Alexander Gladysh
> <agladysh@gmail.com> wrote:
> > Unspecified? Implementation-specific? Undefined sounds scary to me.
> > :-)
> 
> Background:
> http://stackoverflow.com/questions/2397984/undefined-unspecified-and-implementation-defined-behavior
> 
> The Lua Reference Manual briefly uses basically all three terms, but
> I
> don't think it makes a distinction between unspecified and undefined.
> As Roberto says, the Lua interpreter should not crash (though there
> may be an issue of out-of-memory [2] without a special allocator and
> in 5.1 at least certain functions could crash [3]).
> 
> Is it a true statement that Lua 5.1 allows hitting undefined behavior
> in standard C but 5.2 does not?
> 
> [2] http://lua-users.org/lists/lua-l/2008-10/msg00415.html
> [3] http://lua-users.org/lists/lua-l/2008-09/msg00157.html
> 
>