Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <3B9B0C1F.7090504@ece.gatech.edu>
Date: Sun, 09 Sep 2001 02:28:47 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713
X-Accept-Language: en-us
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: binutils auto-import bug
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

With regards to the auto-imported array access bug (not the memory leak 
problem), Paul S. has returned, and submitted a patch to binutils 
mailing list to "fix" it.

I've tested it and it seems to "work", so I'm recommending application.

The reason for the quotation marks is: Paul's patch doesn't actually fix 
the bug.  It just detects the condition that *causes* the bug, prints a 
diagnostic message, and exits with error.

Thus, it refuses to silently create buggy code.  This is good.  It 
doesn't allow you to compile/linkto a DLL "just like linux shared libs" 
(because it doesn't really fix the bug; it just posts a sign saying 
"pothole here").  This is bad.

However, Paul makes a good argument that constant-offset indexing into 
an array exported by a shared lib (DLL) is really bad programming 
anyway, and should be fixed (in the client code).  However, this same 
bug bites you with exported structs (which is NOT bad programming) 
However, when porting a client/DLL to cygwin, at least you can now use a 
constant "#define" idiom for CYGWIN rather than the "if building the DLL 
.... else if linking to DLL .... else if building/linkingto a static lib 
...." gobbledygook.

#ifdef __CYGWIN__
    <type> local_array[];
    <struct_type> * local_struct;
    local_array = imported_array;
    local_struct = &imported_struct;
    <access local_array and local_struct->X  instead of imported_array 
and imported_struct.X (note the '->' vs. '.')>
#else
...
#fi

(Actually, the __CYGWIN__ code is not that terrible, you *could* use it 
for all platforms...Many projects have been willing to completely remove 
data exports from their shared libs in favor of set_ and get_ functional 
interfaces, in order to allow mingw builds to work.  This sort of change 
presented above is minor compared to that, and may be acceptable to a 
lot of projects.)

This is meant as a heads up; for more info check out the thread on the 
binutils list.

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/