[RFC PATCH 03/28] cli: lil: Replace strclone with strdup

[Sean Anderson]

On 7/2/21 6:18 PM, Kostas Michalopoulos wrote:
> On 7/2/2021 4:38 PM, Sean Anderson wrote:
>> I have not. I'm not sure what changes I've made are compatible with the
>> vision he has for LIL. He's CC'd on this series, so perhaps he can
>> comment.
> 
> Yeah, sadly several of the changes i've seen in the code are not
> backwards compatible and backwards compatibility is very important for
> me

I don't intend to keep backward compatibility. The way I see it, U-Boot
has never had a LIL shell before, so there is nothing to break :)

> (this is also why the callback setup is done through a lil_callback
> function instead of exposing a struct: adding new callbacks in the
> future wont break any existing code or application that links to the
> library dynamically).

Well, C has a very nice ABI in some repects. As long as you only append
to that struct you will not break compatibility.

> I might break it before a properly versioned release is made at some
> point in the (not close) future, but that is usually unavoidable
> changes to fix big issues (all cases where that happened are mentioned
> in the site).
> 
> In terms of future changes, i do not plan making any *big* changes -
> and certainly anything i'll make it'll be backwards compatible
> (especially after a versioned release) but one thing that i need to do
> is to improve the interpreter's performance, which will affect its
> internals - two areas i might need to change are how values are
> represented (everything is a string -and things must always behave
> like that- but i may need to cache already parsed non-string values)
> and how the code itself -e.g. in functions- is represented.

One of the nice side-effects of adding a separate parser is that it will
now be very easy to get some performance gains by parsing code once and
then re-using that parse on subsequent evaluations. For example,
functions could be parsed on first use, and cached. Loop bodies could
re-used for subsequent iterations.

> Also i'll most likely add more functions to the library to expose and
> alter internal state (the Free Pascal version of LIL already has some
> of that), but that shouldn't affect much internally.
> 
> Beyond that it will be mainly bugfixes - like a use-after-free case
> with "reflect this" i just fixed and uploaded :-P

As it happens, I ended up removing that because there was no longer a
"rootcode" after removing the parsing step. Perhaps at some point I will
add it back, but I do not see a pressing need for the same level of
dynamicness that you built in originally.

--Sean