Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Date: Mon, 15 Feb 1999 18:22:21 +0200
From: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>
Reply-To: Paul Sokoilovsky <paul-ml AT is DOT lg DOT ua>
Message-ID: <8765.990215@is.lg.ua>
To: Mumit Khan <khan AT xraylith DOT wisc DOT edu>, cygwin AT sourceware DOT cygnus DOT com
Subject: __attribute__((dllimport)) problems with egcs
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Mumit,

      Egcs 1.1.1 has problems with dllimport attribute, inherent from
1.1. Here's sample code to show them:

--------
typedef struct _object {
   int ob_refcnt; struct _typeobject *ob_type;
} PyObject;

extern    __attribute__((dllimport))  PyObject   _Py_NoneStruct ;  

static PyObject *
parse_and_bind(PyObject *self,PyObject *args)
{
  return &_Py_NoneStruct;
}  
---------

  Both C and C++ frontends have problems, C++ fatal ones.

  When that code compiled in C mode, following warning is issued:
---
a.c: In function `parse_and_bind':
a.c:10: warning: return from incompatible pointer type  
--
  Of course, it's not there without __attribute__((dllimport)).


  When compiled in C++ mode, it just crashes. Further
investigation by feeding code directly to cc1plus shows that crash
occurs not on declaring _Py_NoneStruct, but on referencing it
(compiler have time to print "struct PyObject * parse_and_bind(struct
PyObject *, struct PyObject *)"). Then, it seems that referencing
method plays role too: for example, returning structure itself doesn't
cause problems. Crash itself due to null pointer dereference at 0x00438b5f.

Best regards,
 Paul                          mailto:paul-ml AT is DOT lg DOT ua