From owner-freebsd-sparc64@FreeBSD.ORG Thu Feb 26 12:20:34 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA5E016A4CE for ; Thu, 26 Feb 2004 12:20:34 -0800 (PST) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4246943D2D for ; Thu, 26 Feb 2004 12:20:34 -0800 (PST) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (dsl081-189-067.sea1.dsl.speakeasy.net [64.81.189.67]) by blake.polstra.com (8.12.9p2/8.12.9) with ESMTP id i1QKKXtC050245; Thu, 26 Feb 2004 12:20:33 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 26 Feb 2004 12:20:33 -0800 (PST) From: John Polstra To: Garance A Drosihn X-Bogosity: No, tests=bogofilter, spamicity=0.498692, version=0.14.5 cc: freebsd-sparc64@freebsd.org Subject: RE: 64btt cvsup? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 20:20:35 -0000 On 25-Feb-2004 Garance A Drosihn wrote: > At 4:45 PM -0800 2/24/04, John Polstra wrote: >>Well, Modula-3 still thinks time_t is 32 bits, of course. I haven't >>looked at the patches for a 64-bit time_t, so I'm not sure what >>provisions have been made for backward compatibility. > > None. We change the type for __time_t, and recompile everything. > This puts us in the same camp as the amd64 and ia64 ports. We > pretend that the sparc platform never had a 32-bit time_t. > >>I assume you (the collective "you") kept compatibility versions >>of time(2), stat(2), lstat(2), etc., with 32-bit time_t fields >>so that existing executables would continue to work. > > No. Ugh. Do you folks fully realize the implications of that? Consider the numerous as-yet unidentified pieces of code out there that look like this: #include void func(void) { int a; time_t t; int b; /* ... */ time(&t); /* ... */ } All of a sudden, without any warning, the time() call is likely to start scribbling a 0 into either "a" or "b" -- or, worse yet, into half of the return address or frame pointer. Who knows what the symptoms of that will be? Will they be deterministic? Will they cause ugly security vulnerabilities? Whee! I don't have a SPARC machine, so it's no skin off my nose. But I think you folks might come to regret it if you take this shortcut. This platform has already been around for a year, and people have developed certain expectations. You can't just say, "We warned you," and expect that to make everything all right. You're likely to end up with a whole bunch of unhappy users with broken machines and no workable path forward or backward. Have fun dealing with that! :-) I've been around here since 1995, and I've seen people talk themselves into skipping the backward-compatibility step before. They practically always regretted it. I think this is likely to be one of those cases. John