X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Message-ID: <4AEF5B7C.90600@cygwin.com> Date: Mon, 02 Nov 2009 17:21:48 -0500 From: "Larry Hall (Cygwin)" Reply-To: cygwin AT cygwin DOT com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090320 Remi/2.0.0.21-1.fc8.remi Lightning/0.9 Thunderbird/2.0.0.21 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Shall dlopen("foo") succeeed if only "foo.dll" exists? References: <20091102164807 DOT GA2897 AT calimero DOT vinschen DOT de> <4AEF305E DOT 1010105 AT cygwin DOT com> <20091102203348 DOT GC6836 AT calimero DOT vinschen DOT de> In-Reply-To: <20091102203348.GC6836@calimero.vinschen.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On 11/02/2009 03:33 PM, 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 >>> fully. >> >> 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. Ah, now that's starting to ring a bell. OK, I understand why it was put in. I guess I would come down on the side that we're stuck with Windows implementation here (OK, not entirely true but...) so trying to circumvent something that Windows allows probably just makes things more difficult. For instance, going back to my comment about the need to make a source level change here anyway, if we don't do checking in dlopen(), 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, 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, I'm wondering if it really doesn't have any merit. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _____________________________________________________________________ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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