From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 8 16:33:40 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 653CA16A41F for ; Sat, 8 Oct 2005 16:33:40 +0000 (GMT) (envelope-from andreas.kohn@gmx.net) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 8E00143D45 for ; Sat, 8 Oct 2005 16:33:39 +0000 (GMT) (envelope-from andreas.kohn@gmx.net) Received: (qmail invoked by alias); 08 Oct 2005 16:33:38 -0000 Received: from unknown (EHLO klamath) [212.204.44.203] by mail.gmx.net (mp015) with SMTP; 08 Oct 2005 18:33:38 +0200 X-Authenticated: #2431876 From: Andreas Kohn To: Peter Jeremy In-Reply-To: <20051007205422.GW72352@cirb503493.alcatel.com.au> References: <1128644542.1273.36.camel@klamath.syndrom23.de> <20051007162846.GB12691@odin.ac.hmc.edu> <1128709063.1022.9.camel@klamath.syndrom23.de> <20051007205422.GW72352@cirb503493.alcatel.com.au> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-HVTg69TJ9EKbvI5NUawt" Date: Sat, 08 Oct 2005 18:33:36 +0200 Message-Id: <1128789216.997.8.camel@klamath.syndrom23.de> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 FreeBSD GNOME Team Port X-Y-GMX-Trusted: 0 Cc: freebsd-hackers@freebsd.org Subject: Re: struct timeval: why is tv_sec long? 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: Sat, 08 Oct 2005 16:33:40 -0000 --=-HVTg69TJ9EKbvI5NUawt Content-Type: multipart/mixed; boundary="=-ECAYTdel80Axb+UDB8nf" --=-ECAYTdel80Axb+UDB8nf Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, On Sat, 2005-10-08 at 06:54 +1000, Peter Jeremy wrote: > On Fri, 2005-Oct-07 20:17:43 +0200, Andreas Kohn wrote: > >As SUSv2 wants tv_sec to be time_t[1], would it be possible to change > >this to time_t on all but alpha? I guess alpha will not receive a switch > >to long anymore[2].=20 >=20 > tv_sec and time_t are int on Alpha for compatability with Tru64. Since > the Alpha is now a dead architecture and no longer a tier-1 FreeBSD > platform, it's unlikely anyone will expend the effort to change them. That's what I was implying, yes. So, is there any reason left (except perhaps envious looks from the alpha guys :D) not to change it?=20 Shall I open up a PR on this? The only thing I'm currently wondering if it would be better to do=20 --- sys/_timeval.h #ifdef __alpha__ long tv_sec; #else time_t tv_sec; #endif ---, or creating a machine/_timeval.h. #ifdef __alpha__ would probably okay, there are more files in sys/ that do that. I think this is an important issue, as it currently makes code not compile on FreeBSD that uses standard interfaces.=20 Attached is a patch to at least update gettimeofday(2) with the fact that tv_usec is suseconds_t, and add a BUGS section to note the problem with tv_sec. I was unsure whether to add the reasoning behind the problem (alpha, tru64), so I left that out. Best regards, Andreas --=20 was macht man eigentlich auf einer linux-gamer lan ? hl server aufsetzen und freuen ? *duck* ^^ --=-ECAYTdel80Axb+UDB8nf Content-Disposition: attachment; filename=gettimeofday.2.diff Content-Transfer-Encoding: base64 Content-Type: text/x-patch; name=gettimeofday.2.diff; charset=UTF-8 SW5kZXg6IGdldHRpbWVvZmRheS4yDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL3N0b3JhZ2UvZnJl ZWJzZC9jdnMvc3JjL2xpYi9saWJjL3N5cy9nZXR0aW1lb2ZkYXkuMix2DQpyZXRyaWV2aW5nIHJl dmlzaW9uIDEuMjUNCmRpZmYgLXUgLXIxLjI1IGdldHRpbWVvZmRheS4yDQotLS0gZ2V0dGltZW9m ZGF5LjIJMiBKdWwgMjAwNCAyMzo1MjoxMyAtMDAwMAkxLjI1DQorKysgZ2V0dGltZW9mZGF5LjIJ OCBPY3QgMjAwNSAxNjoyNzo0MCAtMDAwMA0KQEAgLTgyLDggKzgyLDggQEANCiAuUHANCiAuQmQg LWxpdGVyYWwNCiBzdHJ1Y3QgdGltZXZhbCB7DQotCWxvbmcJdHZfc2VjOwkJLyogc2Vjb25kcyBz aW5jZSBKYW4uIDEsIDE5NzAgKi8NCi0JbG9uZwl0dl91c2VjOwkvKiBhbmQgbWljcm9zZWNvbmRz ICovDQorCWxvbmcJCXR2X3NlYzsJCS8qIHNlY29uZHMgc2luY2UgSmFuLiAxLCAxOTcwICovDQor CXN1c2Vjb25kc190CXR2X3VzZWM7CS8qIGFuZCBtaWNyb3NlY29uZHMgKi8NCiB9Ow0KIA0KIHN0 cnVjdCB0aW1lem9uZSB7DQpAQCAtMTMzLDMgKzEzMyw1IEBADQogLkZuIGdldHRpbWVvZmRheQ0K IHN5c3RlbSBjYWxsIGFwcGVhcmVkIGluDQogLkJ4IDQuMiAuDQorLlNoIEJVR1MNCitUaGUgdHZf c2VjIG1lbWJlciBvZiBzdHJ1Y3QgdGltZXZhbCBzaG91bGQgYmUgYSB0aW1lX3QuDQo= --=-ECAYTdel80Axb+UDB8nf-- --=-HVTg69TJ9EKbvI5NUawt Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDR/TgYucd7Ow1ygwRAtxsAKCQ42xqMNKkw19ZuPav2tTYGeR0NgCgmbky VKIdCI/TEkI+Za3tQzJbxOs= =iRGc -----END PGP SIGNATURE----- --=-HVTg69TJ9EKbvI5NUawt--