From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 5 20:17:40 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2393E106566B for ; Sun, 5 Jun 2011 20:17:40 +0000 (UTC) (envelope-from ben@links.org) Received: from mail.links.org (mail.links.org [217.155.92.109]) by mx1.freebsd.org (Postfix) with ESMTP id CAB6F8FC0A for ; Sun, 5 Jun 2011 20:17:39 +0000 (UTC) Received: from [193.133.15.218] (localhost [127.0.0.1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.links.org (Postfix) with ESMTPS id 85A9D33C1D; Sun, 5 Jun 2011 21:17:38 +0100 (BST) Message-ID: <4DEBE469.5060305@links.org> Date: Sun, 05 Jun 2011 21:17:45 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Poul-Henning Kamp References: <11705.1307298084@critter.freebsd.dk> In-Reply-To: <11705.1307298084@critter.freebsd.dk> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: int64_t and printf X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 20:17:40 -0000 On 05/06/2011 19:21, Poul-Henning Kamp wrote: > In message <4DEBC741.1020200@links.org>, Ben Laurie writes: > >> So, for example int64_t has no printf modifier I am aware of. Likewise >> its many friends. > >> but I have no idea where to put such a thing in FreeBSD. Opinions? > > I have totally given up on this mess. > > At best you get incredibly messy source code, at worst you waste a > lot of time figuring out why who to define stuff to make some platform > you have only heard rumours about behave. > > I have therefore resorted to printf'ing any typedefed integer type using > "%jd" and an explicit cast to (intmax_t): > > printf("%-30s -> %jd -> %s\n", s, (intmax_t)t, buf); > > If some system introduces int512_t that may not be optimal, but > since printf is a pretty slow operation anyway, I doubt it will > hurt even half as much as the alternative. My objection to this approach is the lack of type-safety - t could be anything and this would continue to work. Using PRId64 at least ensures that t is of an appropriate type. One way to get the best of both worlds is to at least ensure that t is of the type you think it is before casting, but this also leads to messy code - the best I can think of would look like printf("%-30s -> %jd -> %s\n", s, cast(int64_t, intmax_t, t), buf); Is this really better than printf("%-30s -> %" PRId64 " -> %s\n", s, t, buf); ? Mere character count would suggest not. Providing a better printf seems like an even smarter idea, e.g. printf("%-30s -> %I64d -> %s\n", s, t, buf); -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff