From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 14:52:35 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 63E56D64 for ; Tue, 19 Feb 2013 14:52:35 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by mx1.freebsd.org (Postfix) with ESMTP id 1A7B3AD9 for ; Tue, 19 Feb 2013 14:52:34 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id j8so1863055qah.0 for ; Tue, 19 Feb 2013 06:52:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2jhdJ42H/K3SeYoCe+6gF4JAJ2wO1japTLtRDgQQcio=; b=h5lTdTfS8BajI/ZauIy571mvesOaDqjeZLwBe5UqvSD/m76lVVV0XGGF/jpL6E1yQQ QzGGl3CMEB8orx8rCiuNx1swW8igf5PsQdlwMcIWg0qcsF4jn6jUrP3kY05DLUUueMST M8/CghUpR+H0QvIAFKYdQi+6gBWS8kz8TIvj/iipPwwGbDuTPZzVTo/frKjOex2bMuav TME2F0Q925fu12pEFtue3BI470mSYLkS9++kVTkaneWaFEq3xCKm78+m6AR5RkG49REd tmShJarQMVlIk063ANrDpfPNVfbfHA6rUhThIgc7zCUNn6kwt1yThnl/gGaZA6/RWnin lX5A== MIME-Version: 1.0 X-Received: by 10.49.95.166 with SMTP id dl6mr7378314qeb.33.1361285554258; Tue, 19 Feb 2013 06:52:34 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.229.179.42 with HTTP; Tue, 19 Feb 2013 06:52:34 -0800 (PST) In-Reply-To: <77B93E04-9254-4EF1-8BDB-ED9214CEC2BC@sarenet.es> References: <77B93E04-9254-4EF1-8BDB-ED9214CEC2BC@sarenet.es> Date: Tue, 19 Feb 2013 06:52:34 -0800 X-Google-Sender-Auth: lSzbhH5hTqDK2CRuxr6xwvuBkPg Message-ID: Subject: Re: Stupid question about integer sizes From: mdf@FreeBSD.org To: Borja Marcos Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 14:52:35 -0000 On Tue, Feb 19, 2013 at 5:11 AM, Borja Marcos wrote: > > Hello, > > I'm really sorry if this is a stupid question, but as far as I know, u_int64_t defined in /usr/include/sys/types.h should *always* be > a 64 bit unsigned integer, right? > > Seems there's a bug (or I need more and stronger coffee). Compiling a program on a 64 bit system with -m32 gets the 64 bit integer types wrong. > > % cat tachin.c > #include > #include > > > main() > { > printf("sizeof uint64_t = %d\n", sizeof(uint64_t)); > printf("sizeof u_int64_t = %d\n", sizeof(u_int64_t)); > } > > > > uname -a > FreeBSD splunk 9.1-RELEASE FreeBSD 9.1-RELEASE #14: Wed Jan 23 17:24:05 CET 2013 root@splunk:/usr/obj/usr/src/sys/SPLUNK amd64 > > % gcc -o tachin tachin.c > % ./tachin > sizeof uint64_t = 8 > sizeof u_int64_t = 8 > > % ./tachin > sizeof uint64_t = 4 <======= WRONG!! > sizeof u_int64_t = 4 <======= WRONG!! > > The same happens with clang. > > % clang -m32 -o tachin tachin.c > tachin.c:5:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] > main() > ^~~~ > 1 warning generated. > % ./tachin > sizeof uint64_t = 4 <======= WRONG!! > sizeof u_int64_t = 4 <======= WRONG!! > > > if I do the same on a i386 system (8.2-RELEASE, but it should be irrelevant) the u_int64 types have the correct size. > > %gcc -o tachin tachin.c > %./tachin > sizeof uint64_t = 8 > sizeof u_int64_t = 8 > > > > > > Am I missing anything? Seems like a too stupid problem to be a real bug. Sorry if I am wrong. > Last I knew -m32 still wasn't quite supported on 9.1. This is fixed in CURRENT. The problem in in the machine-dependent headers. sys/types.h includes sys/_types.h which includes machine/_types.h. But the machine alias can only point to one place; it's the amd64 headers since you're running the amd64 kernel. sys/amd64/include/_types.h defines __uint64_t as unsigned long, which is correct in 64-bit mode but wrong in 32-bit mode. On CURRENT there is a merge x86/_types.h which uses #ifdef guards to define __uint64_t as unsigned long or unsigned long long, depending on __LP64__, so that the size is correct on a 32-bit compiler invocation. Cheers, matthew