Re: [ANN] Lua 5.2.0 (beta-rc2) now available

[Jerome Vuarand <jerome.vuarand@...>]

2011/6/22 steve donovan <steve.j.donovan@gmail.com>:
> On Wed, Jun 22, 2011 at 12:21 AM, Luiz Henrique de Figueiredo
> <lhf@tecgraf.puc-rio.br> wrote:
>> All feedback welcome. Thanks.
>
> Just an observation about the folly of depending on undocumented internals.
>
> Previously people could hijack the existing file objects by packing
> their own FILE* in the LUA_FILEHANDLE userdata, which was just FILE**.
>  Now that userdata looks like this:
>
> typedef struct LStream {
>   FILE *f;  /* stream */
>   lua_CFunction closef;  /* to close stream (NULL for closed streams) */
>  } LStream;
>
> (LuaJIT uses something similar)
>
> I mention this because I think there's a need for a standard way for
> extensions to create Lua file objects, or even on level of a
> 'io.fdopen' function that would create a file object from an existing
> file-like handle.  One particular use case would be a Windows
> extension wishing to provide a UTF-8 aware io.open, or to redefine
> io.popen so it does not depend on the particular broken implementation
> of the Windows CRT.

The API of the file objects is clearly defined in the manual, you can
implement a new function io.open that would return your own userdata
(or a table) with the right methods. If you properly override io.type
any Lua code will still work. That would only break C modules that
don't use the object methods like Lua code would, but rather decided
to assume they know the (undocumented) content of the file userdata
and called fread/fwrite directly.