[Bug other/12782] New: ffi.h #defines ffi_type_[us]long wrong on 32bit arches

[Bug other/12782] New: ffi.h #defines ffi_type_[us]long wrong on 32bit arches

[a dot rottmann at gmx dot at]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12782

           Summary: ffi.h #defines ffi_type_[us]long wrong on 32bit arches
           Product: gcc
           Version: 3.3.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: other
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: a dot rottmann at gmx dot at
                CC: gcc-bugs at gcc dot gnu dot org

The way ffi.h #defines the ffi_type_XX equivalents to the standard C
types seems bad - they are mixed along with the #defines of the
fixed-bit types (e.g. UINT32), but the two issues are orthogonal. 

This results in ffi_type_ulong, for instance, being #defined to ffi_type_uint64
on (at least) x86, as the following test program indicates:

#include <stdio.h>
#include <ffi.h>

int main ()
{
  printf ("&ffi_type_ulong: %p &ffi_type_uint64: %p\n", 
          &ffi_type_ulong, &ffi_type_uint64);
}

This results in the following output on my Athlon (no, no Athlon64 yet ;-))

&ffi_type_ulong: 0x8049738 &ffi_type_uint64: 0x8049738

[Bug other/12782] ffi.h #defines ffi_type_[us]long wrong on 32bit arches

[a dot rottmann at gmx dot at]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12782



------- Additional Comments From a dot rottmann at gmx dot at  2003-10-27 00:47 -------
Created an attachment (id=5005)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=5005&action=view)
Fix ffi_type_X #defines

The patch should fix this bug, makes the #ifdef nesting more readable by using
#elif and adds #defines for 'long long' and 'unsigned long long'.

[Bug other/12782] ffi.h #defines ffi_type_[us]long wrong on 32bit arches

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12782


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |theller at python dot net


------- Additional Comments From pinskia at gcc dot gnu dot org  2003-10-27 00:55 -------
*** Bug 9398 has been marked as a duplicate of this bug. ***

[Bug other/12782] ffi.h #defines ffi_type_[us]long wrong on 32bit arches

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12782


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2003-10-27 00:58:14
               date|                            |
   Target Milestone|---                         |3.4


------- Additional Comments From pinskia at gcc dot gnu dot org  2003-10-27 00:58 -------
Could you patch the one in the sources called ffi.h.in (make sure that it is the mainline sources) in 
gcc/libffi/include and make a changelog and post the patch with the changelog to gcc-
patches@gcc.gnu.org.  Note GCC is not the official maintainers of libffi yet.

[Bug other/12782] ffi.h #defines ffi_type_[us]long wrong on 32bit arches

[a dot rottmann at gmx dot at]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12782



------- Additional Comments From a dot rottmann at gmx dot at  2003-10-27 09:48 -------
The ffi.h[.in] file changed a bit since the gcc 3.3.2 release. Now (in CVS) it
blatantly says:

#define ffi_type_ulong         ffi_type_uint64
#define ffi_type_slong         ffi_type_sint64

without any condition (the other types seem OK now). I cannot image that this is
intended behavior -- there should be ffi_type_[us]long _and_
ffi_type_[us]long_long types; how would you else describe a function that takes
(or returns) a 'long' -- you cannot tell for sure that long is a specific size...

[Bug other/12782] ffi.h #defines ffi_type_[us]long wrong on 32bit arches

[green at redhat dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12782


green at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2003-10-27 00:58:14         |2003-10-31 06:14:56
               date|                            |


------- Additional Comments From green at redhat dot com  2003-10-31 06:14 -------
Yes, this is wrong.  We should use tests to define ffi_type_[us]long like the
other types descriptors above it.

[Bug other/12782] ffi.h #defines ffi_type_[us]long wrong on 32bit arches

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |green at redhat dot com
                   |dot org                     |
   Target Milestone|3.4.0                       |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12782