Re: Make "package.loaded" weak

[Martin <eden_martin_fuhrspam@...>]

On 02/18/2017 01:50 PM, Sean Conner wrote:
>   So ... you do a one time calculation (or few) and that's it?  Once?  No
> more during the lifetime of the program?  Seems like an odd case (or
another
> weak example).  Because if that's the case, then I would do something
like:
>
>   local get_crc = require "get_crc"
>
>   local crc_table = get_crc("CRC_2bytes_EDB88320")
>
>   And get_crc() will load up the precalucated table (say, with loadfile())
> and return it.  So you could, for example, later on do:
>
>   local crc_table = get_crc("CRC_2bytes_12345678")

Yes, this is reliable design solution. More rugged than flexible.
But what if I wish maximum flexibility Lua can offer? CRC calculation
loop by nature dont care about contents of CRC-table. It only has to
be indexable and contain xor-able values.

So my intention for this abstract example is to provide CRC-table
as independent argument (of class field).

  local crc
  do
    local custom_tbl = {<values created by hand>}
    crc = require('get_crc')(custom_tbl)
  end
  print('crc', crc)

But code with mix of constants and logic for me looks ugly and
unflexible. So my intention is to separate constants. And moving
constants to separate module looks natural idea. But then memory
pollution starts.


Probably I cannot afford another more "strong" example.

For me even a one unneeded record in memory is a reason to think how
it occurred there. Why modules that was called in load stage of
code execution (say some format parser intrinsics) still in memory
in save stage? Example with CRC table pollution may be avoided
by design or by implementation. But my intention is not to force
some changes by providing unsolvable case but only point to and
discuss some topics.


On 02/18/2017 01:50 PM, Sean Conner wrote:
>  those crackers are nothing if persistent.
>   Non-executable stacks?  Okay, we'll use ROP.  Oh, randomize all
>   function addresses?  We can work around that too (in JavaScript no
>   less [4]).

They don't create problems, they demonstrate it.

--

I'll try to summarize my views and recommendations received:


Why use "require()" not "dofile()", "load()" or "io.read()"?

  1. With "require()" you do not have to think about paths for
    "dofile()" or string source for "load()" or create custom format
    loader for "io.read()".
  2. "require()" may (or must?) return cache of loaded data for
    repeated calls. This eliminates redundant file I/O operations.

Why not nil "package.loaded"?

  1. Appropriate solution if implement it as "weak_require()" wrapper,
    as Francisco recommended.

Why not make "package.loaded" weak?

  1. Daurminator mentioned possible problems with C modules.
  2. Rena mentioned possible problems with modules creating files
    or setting global variables at load.

-- Martin