This is the mail archive of the
mailing list for the Cygwin project.
Re: Shall dlopen("foo") succeeed if only "foo.dll" exists?
On Mon, Nov 02, 2009 at 09:33:49PM +0100, Corinna Vinschen wrote:
>On Nov 2 14:17, Larry Hall (Cygwin) wrote:
>> On 11/02/2009 11:48 AM, Corinna Vinschen wrote:
>> >For 1.7 our choice is to keep dlopen() checking for the .dll suffix to
>> >be more Windows-like, or to be more Linux-like by dropping the check for
>> >the .dll suffix so that dlopen() fails if the filename isn't specified
>> OK, I'll admit I'm responding with a question without actually looking at the
>> code and so one can feel free to ignore me. However the thought that came
>> to my mind is, should it really matter if dlopen() checks? What does the check
>> give us that just passing the name along to LoadLibrary() doesn't? At first
>> impression, doing the check just prematurely rejects names without
>> the DLL suffix
>> that would otherwise be accepted by Windows. Since there's a source
>> level change
>> that (typically) needs to happen to make the code work on Windows as opposed
>> to Linux/Unix, what benefit are we getting from this added check?
>Good question, that's exactly why I'm asking.
>Answer: Nothing but *maybe* a less surprising behaviour in terms of
>POSIX compatibility. Allowing automatic file extension is not part of
>the standards and not even mentioned as a possible option. Sure, if
>that's nothing to worry about, we can stick to the current behaviour.
There is already .dll mumbo jumbo going on in dlopen. I'd rather just
remove it and make it behave as much like linux as possible, especially
since 1.7 has so many other changes to backwards comtemptibility.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple