From owner-freebsd-hackers Mon Sep 2 14:54:11 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEDCE37B409 for ; Mon, 2 Sep 2002 14:53:59 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3389543E75 for ; Mon, 2 Sep 2002 14:53:59 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id E3A992A893; Mon, 2 Sep 2002 14:53:58 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon Cc: hackers@FreeBSD.ORG Subject: Re: 64 bit API/ABI changes proposal for -current In-Reply-To: <200209022104.g82L4mdf033101@apollo.backplane.com> Date: Mon, 02 Sep 2002 14:53:58 -0700 From: Peter Wemm Message-Id: <20020902215358.E3A992A893@canning.wemm.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > :4) Changing time_t to 64 bit using long long on a native 32 bit platform > :is a f*cking nightmare. I've tried this and it got very nasty very quickly. > > This is not what I proposed. I proposed adding new system calls to > completely and permanently fix all of our outstanding issues and then > providing a compiler option to allow developers to select which API > they want presented. Well, one thing that I would not be against is a clean divorce of the syscall layer and libc. That then gives us the freedom to implement alternative API selections etc at compile time pretty easily. I just really do not want to see this sort of thing turning up: time_t foo = time(0); printf("the time is %lld\n", (long long)foo); /* i386 compatability */ .. because that hurts our 64 bit platforms down the road when long long becomes 128 bit. intmax_t/%j etc has similar problems as it then takes the native 64 bit time type (long) and converts it to a synthetic 128 bit type. ie: %j and intmax_t etc are just as bad. My first exposure to a unix OS had some pretty horrific stat structure versioning and evilness (svr4). It was a real nightmare, except you never got to wake up and discover that it was all over. I am not against providing 64 bit extentions for 32 bit systems, but it really needs to be done so that it all becomes a giant NOP when on native 64 bit systems. Something like the large-file-summit API extensions that all magically go away after the transition period or when you get a chance to do a total ABI breakaway. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message