<20091102203348.gc6...@calimero.vinschen.de>
<4aef5b7c.90...@cygwin.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
> Date: Mon=2C 2 Nov 2009 17:21:48 -0500
> From: Larry Hall
> Subject: Re: Shall dlopen("foo") succeeed if only "foo.dll" exists?
>
> On 11/02/2009 03:33 PM=2C Corinna Vinschen wrote:
>> On Nov 2 14:17=2C Larry Hall (Cygwin) wrote:
>>> On 11/02/2009 11:48 AM=2C Corinna Vinschen wrote:
>>>> For 1.7 our choice is to keep dlopen() checking for the .dll suffix to
>>>> be more Windows-like=2C or to be more Linux-like by dropping the check=
for
>>>> the .dll suffix so that dlopen() fails if the filename isn't specified
>>>> fully.
>>>
>>> OK=2C I'll admit I'm responding with a question without actually lookin=
g at the
>>> code and so one can feel free to ignore me. However the thought that ca=
me
>>> to my mind is=2C should it really matter if dlopen() checks? What does =
the check
>>> give us that just passing the name along to LoadLibrary() doesn't? At f=
irst
>>> impression=2C 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 op=
posed
>>> to Linux/Unix=2C what benefit are we getting from this added check?
>>
>> Good question=2C 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=2C if
>> that's nothing to worry about=2C we can stick to the current behaviour.
>
> Ah=2C now that's starting to ring a bell. OK=2C I understand why it was p=
ut in.
>
> I guess I would come down on the side that we're stuck with Windows
> implementation here (OK=2C not entirely true but...) so trying to circumv=
ent
> something that Windows allows probably just makes things more difficult.
> For instance=2C going back to my comment about the need to make a source
> level change here anyway=2C if we don't do checking in dlopen()=2C such a
> change could be avoided. I'm thinking of a case where foo.so is the Linux
> name and the makefile is altered (instead) to generate foo.so.dll for
> Cygwin. OK=2C I expect this isn't going to be the average case by any
> stretch of the imagination but it still seems like it's a nice "feature" =
that
> someone might want to leverage. The only advantage I can see to leaving
> the current checks in place is to be more dogged in our attempts to be
> POSIX compliant. I don't object to POSIX but in this case=2C I'm wonderin=
g
> if it really doesn't have any merit.
>
But this does not seem to be about POSIX compliance=2C insted it seems (to =
me)
to be about non-POSIX non-compliance=2C for which we have no requirement.
...Karl =20
_________________________________________________________________
Bing brings you maps=2C menus=2C and reviews organized in one place.
http://www.bing.com/search?q=3Drestaurants&form=3DMFESRP&publ=3DWLHMTAG&cre=
a=3DTEXT_MFESRP_Local_MapsMenu_Resturants_1x1=
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
