Re: rewrite try_dlopen (2)

[Ralf Wildenhues]

Hi Bob,

* Bob Friesenhahn wrote on Tue, Oct 05, 2004 at 04:47:36PM CEST:
> On Tue, 5 Oct 2004, Ralf Wildenhues wrote:
> >
> >Are you arguing that we should disregard this feature request?  From
> >libtool/TODO section 2.5:
> >
> >| * Godmar Back writes:
> >|   libltdl uses such stdio functions as fopen, fgets, feof, fclose, and 
> >others.
> >|   These functions are not async-signal-safe. While this does not make
> >|   libltdl unusable, it restricts its usefulness and puts an
> >|   unnecessary burden on the user.
> >|
> >|   As a remedy, I'd recommend to replace those functions with functions
> >|   that POSIX says are async-signal-safe, such as open, read, close.
> >|   This will require you to handle interrupted system calls and implement
> >|   fgets, but the former isn't hard and there's plenty of implementations
> >|   out from which you can steal the latter.
> >|
> >|   I believe relying on async-signal-safe functions to the greatest extent
> >|   possible would greatly improve libltdl's ability to be embedded in and
> >|   used by other systems.
> 
> I was not aware of this TODO section.  The purpose/need for 
> async-signal-safe functions is for them to be safe for use from within 
> signal handlers.  It has nothing to do with usability outside of 
> signal handlers.  Libltdl does not use any signal handlers.
> 
> In what case might someone want to invoke libltdl functions from a 
> signal handler?  I think that this would be a very unwise thing to do, 
> regardless of implementation.

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?

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

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.

> >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.

Regards,
Ralf