From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-hacker-return-8889-listarch-libc-hacker=sources.redhat.com@sourceware.org>
Received: (qmail 19132 invoked by alias); 28 Feb 2006 12:50:28 -0000
Received: (qmail 19116 invoked by uid 22791); 28 Feb 2006 12:50:28 -0000
X-Spam-Check-By: sourceware.org
Received: from sunsite.ms.mff.cuni.cz (HELO sunsite.mff.cuni.cz) (195.113.15.26)
    by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 28 Feb 2006 12:50:25 +0000
Received: from sunsite.mff.cuni.cz (sunsite.mff.cuni.cz [127.0.0.1])
	by sunsite.mff.cuni.cz (8.13.1/8.13.1) with ESMTP id k1SCoLTX031575;
	Tue, 28 Feb 2006 13:50:21 +0100
Received: (from jj@localhost)
	by sunsite.mff.cuni.cz (8.13.1/8.13.1/Submit) id k1SCoLZZ031574;
	Tue, 28 Feb 2006 13:50:21 +0100
Date: Tue, 28 Feb 2006 12:50:00 -0000
From: Jakub Jelinek <jakub@redhat.com>
To: Ulrich Drepper <drepper@redhat.com>, Roland McGrath <roland@redhat.com>
Cc: Glibc hackers <libc-hacker@sources.redhat.com>
Subject: [PATCH] Fix int64_t/u_int64_t on 64-bit arches with non-GCC compilers
Message-ID: <20060228125020.GF30252@sunsite.mff.cuni.cz>
Reply-To: Jakub Jelinek <jakub@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Mailing-List: contact libc-hacker-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:libc-hacker-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-hacker/>
List-Post: <mailto:libc-hacker@sourceware.org>
List-Help: <mailto:libc-hacker-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-hacker-owner@sourceware.org
X-SW-Source: 2006-02/txt/msg00060.txt.bz2

Hi!

On 64-bit arches and non-GCC compilers, <sys/types.h> uses long long resp.
unsigned long long types for int64_t/u_int64_t.  But, <stdint.h> uses
there long resp. unsigned long and so does <sys/types.h> for GCC
(it uses DImode int, which mangles as l rather than x).
With those compilers, depending if you include <stdint.h> or <sys/types.h>
first thus affects mangling, the same function can mangle differently
based on the order of the above headers included.

The following patch is an ABI change with those compilers, makes even
non-GCC compilers do the same as GCC (and the same as <stdint.h> already
does).

2006-02-28  Jakub Jelinek  <jakub@redhat.com>

	* posix/sys/types.h [!__GNUC_PREREQ (2, 7)] (int64_t, u_int64_t):
	typedef to long int resp. unsigned long int on 64-bit arches.

--- libc/posix/sys/types.h.jj	2002-10-24 01:48:51.000000000 +0200
+++ libc/posix/sys/types.h	2006-02-28 13:34:44.000000000 +0100
@@ -1,4 +1,4 @@
-/* Copyright (C) 1991,1992,1994,1995,1996,1997,1998,1999,2000,2001,2002
+/* Copyright (C) 1991,1992,1994,1995,1996,1997,1998,1999,2000,2001,2002,2006
    	Free Software Foundation, Inc.
    This file is part of the GNU C Library.
 
@@ -163,7 +163,9 @@ typedef unsigned int uint;
 typedef	char int8_t;
 typedef	short int int16_t;
 typedef	int int32_t;
-#  if __GLIBC_HAVE_LONG_LONG
+#  if __WORDSIZE == 64
+typedef long int int64_t;
+#  elif __GLIBC_HAVE_LONG_LONG
 __extension__ typedef long long int int64_t;
 #  endif
 # endif
@@ -172,7 +174,9 @@ __extension__ typedef long long int int6
 typedef	unsigned char u_int8_t;
 typedef	unsigned short int u_int16_t;
 typedef	unsigned int u_int32_t;
-# if __GLIBC_HAVE_LONG_LONG
+# if __WORDSIZE == 64
+typedef unsigned long int u_int64_t;
+# elif __GLIBC_HAVE_LONG_LONG
 __extension__ typedef unsigned long long int u_int64_t;
 # endif
 

	Jakub