Re: [TCLCORE] GSoC ShlibMemLoad

[Andreas K. <and...@ac...>]

> > > > /17/      Create an unload function in the vein of TclpUnloadFile().
> > > /18/      Add elf_dlclose to the set of function to analyse and
> > >          understand per tasks /14/, /15/ and /16/.
> >
> > Mostly done. I have not written descriptions yet.
>
> Will reviewing this (repository revision 11), more in a second
> mail after I digested your changes ...

TclpUnloadFile().

(i)	It seems I fumbled my explanations here. When TCL_LOAD_FROM_MEMORY is
	active Tcl has to be extended with the ability to load libraries from
	memory. Its existing ability to load libraries from disk must not be
	impaired.

	For TclpUnloadFile() this means that we cannot switch its
	implementation between normal and TCL_LOAD_FROM_MEMORY. This function
	is for the normal	path and must not change. What is needed for
	TCL_LOAD_FROM_MEMORY (and TclpLoadFromMemory()) is a new/separate
	function, say TclpUnloadMemory(), whose implementation is modeled
	after the implementation of TclpUnloadFile(), containing the specifics
	for TCL_LOAD_FROM_MEMORY.

	For TclpLoadMemory() this means that unloadProcPtr has to refer to
	this new function instead of TclpUnloadFile().

(ii)	A minor quibble I have with TclpLoadMemory() is that the code
	constructing the error message still refers to 'pathPtr'.
	A variable which is gone. This buglet will be caught by
	the compiler.

(iii)	A style quibble. In complex (long) code a construction with
	'goto freeBuffer' and a label 'freeBuffer:' is beneficial.
	Here wrapping the ok case into an 'else' branch of the 'if'
	will do the same and look neater.

configure.in

(iv)	The gcc test you added per my request uses 'Yes', with an uppercase Y.
	If my reading of other places in configure.in and tcl.m4 is right,
	this should be a 'yes', lower-case y. Typo's are the developer's bane.

	See for example line 776 in configure.in for an existing test.

> > I am about to write this email to John Polstra and I really
> > hope he will be helpful.

Please do not forget to cc us on this mail.

--
	Andreas Kupries <andreask@ActiveState.com>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122