Re: Patchless modification of Lua source code

[Dirk Laurie <dirk.laurie@...>]

Op Wo. 21 Nov. 2018 om 01:31 het Viacheslav Usov <via.usov@gmail.com> geskryf:
>
> On Mon, Nov 19, 2018 at 10:10 AM Dirk Laurie <dirk.laurie@gmail.com> wrote:
>
>>
>> 1. All external names used by Lua are declared in header files.
>> 2. If such a name has been resolved by an object file or library
>> linked earlier, the linker will be satisfied and will not replace it.
>> 3. Any .o files needed by the linker will be built automatically from
>> .c files by the Makefile rules.
>
>
> No. Quoting clause 6.9/5 of the C11 standard:
>
> If an identifier declared with external linkage is used in an expression (other than as part of the operand of a sizeof or _Alignof operator whose result is an integer constant), somewhere in the entire program there shall be exactly one external definition for the identifier; otherwise, there shall be no more than one.
>
> (end)
>
> The standard has no concept of "linked earlier" and consequently no primacy of "names linked earlier", and the entire program, including all the libraries, shall have a function with a given name defined at most once. Per clause 4/2, "If a ‘‘shall’’ or ‘‘shall not’’ requirement [...] is violated, the behavior is undefined".
>
> Note that what you do may fail in weird ways even with toolchains that do have the notion of "linked earlier" - precisely because something has been linked earlier. Your application may be using the "modified" functions, while Lua itself and the other libraries use the "original" functions. This would be a special case of generally undefined behaviour.
>
> Do not do this, except for fun.

What you state so categorically and trenchantly may well be true in
other situations, but I would remind you that we are now dealing with
source files that would have worked if used as patched versions of
standard Lua files. The point of the exercise is simply that patching
can be avoided by this trick, for which I claim no originality.

For the 'linux' target of the Makefile supplied with Lua 5.4 work2,
the link step expands to:

   gcc -std=gnu99 -o lua   lua.o mylex.o myctype.o liblua.a -lm -Wl,-E -ldl

The way I understand it, is that the only the three object files
lua.o, mylex.o and myctype.o must not contain a duplicate definition
of an external routine. Only some routines of a library are linked in,
only the ones still unresolved. For example, the C99 math library
contains atanh, but the lua source code does not request it, so it is
not linked into the lua executable.

It seems to me that, if those three files contain a name conflict,
then omitting mylex.o and myctype.o and instead replacing llex.c and
lctype.c by mylex.c and myctype.c respectively, as in effect patching
would do, would contain the same name conflict, contradicting the
assumption that patching would have worked.

Admittedly I do not have the C11 standard open in front of me (which
BTW seems to be totally irrelevant when a program is compiled
according to the gnu99 standard) and am relying solely on about thirty
years' experience as a C programmer.

I apologize for omitting, in the mistaken belief that they would be
implicit to any reasonably experienced reader, the final words "from
liblua.a" from my point number 2,

— Dirk