Re: rewrite try_dlopen (2)

[Bob Friesenhahn]

On Wed, 6 Oct 2004, Ralf Wildenhues wrote:
> I did a tiny bit of research:  This TODO entry is from 1999.  Haven't
> found mailing list archives from that time, but I strongly suspect that
> the aim was not use within a signal handler, but use of ltdl in an
> embedded environment which lacks full libc support.
>
> At that time, I think it would have made sense, too, since there was
> less support for open embedded environments then and libraries like
> newlib did not provide stdio.  Now users have several small libc
> packages to choose from (e.g., newlib, dietlibc, uclibc etc), and what's
> more, these now all support stdio to some extent.
>
> So in light of that, should we just ditch this TODO item?

Without continued demand we should ditch it.  I haven't noticed any 
continuing demand.

> Additionally, should then get_line() be getline() and LIBOBJed in the
> same manner as argz.c?

Gary is best to answer that.

> Slightly independent of this subject, would it be ok for you if ltdl
> avoided *printf() and *scanf()?  Besides a potential efficiency issue,
> they cause a quite noticeable increase in the size of a static binary
> that uses ltdl but not those functions.

Most applications/libraries of any significiant size and which use 
libltdl will already depend on printf()/scanf() in one way or another 
so the penalty has already been paid.  I wouldn't worry terribly much 
about minimum static application size.  The *printf() and *scanf() 
functions often introduce security concerns so if you can reasonably 
do without them then don't use them.

> > > BTW, would mmap be portable enough to be usable?
> >
> > Mmap (or equivalent) is generally available on systems which support
> > shared/dynamic libraries and virtual memory.  Other than embedded type
> > systems (e.g. LynxOS), I have not encountered a modern system which
> > does not support memory mapped files.  Mmap is less portable than
> > read/write, which is less portable than stdio.
>
> Thank you for that information.

I should mention that using a memory mapped approach is most valuable 
if the file must be read repeatedly since once the file has been 
accessed once, it is already in memory, avoiding additional 
expendatures of CPU and avoiding memory-memory copies.  However, .la 
files are so small they would usually fit in one MMU page.  In this 
case, the system calls themselves may become the dominant overhead, 
eliminating any actual benefits.

Bob
======================================
Bob Friesenhahn
address@hidden
http://www.simplesystems.org/users/bfriesen