From owner-freebsd-hackers  Fri Jun 16 21:04:12 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id VAA04147
          for hackers-outgoing; Fri, 16 Jun 1995 21:04:12 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA04137
          for <hackers@freebsd.org>; Fri, 16 Jun 1995 21:04:05 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id NAA12478; Sat, 17 Jun 1995 13:58:16 +1000
Date: Sat, 17 Jun 1995 13:58:16 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199506170358.NAA12478@godzilla.zeta.org.au>
To: ache@astral.msk.su, terry@cs.weber.edu
Subject: Re: penalty of using off_t for arithmatic with gcc's long
Cc: hackers@freebsd.org, peter@haywire.DIALix.COM
Sender: hackers-owner@freebsd.org
Precedence: bulk

>1) I say nothing here about atomic off_t, I say about "long" type
>of fseek argument, you can see it in any POSIX docs copy.

>2) In my POSIX specs (maybe I look at wrong place?) I don't read
>that off_t must be atomic, it says "integral".

"atomic" is bogus.  My copy of the POSIX specs says that it must be
"signed arithmetic".  This sloppy wording seems to allow it to be
long double, but maybe "signed integer" is meant.  ANSI only specifies
"signed" in connection with integer types.

>>> If you include <unistd.h>, you don't need to cast lseek() argument to off_t.

Also if you include <sys/types.h> or anything that includes it (e.g.,
<stdio.h> bogusly includes it).

>>Because the prototype hides the bogosity from you ...a bad thing if you
>>move the code between non-POSIX/non-ANSI 100% compliant systems -- like
>>BSD.  BSD just doesn't have this particular non-compliance bogosity,
>>which doesn't guarantee that it doesn't have others.

Which bogosities?  long long isn't an arithmetic type so it is bogus to use
it for off_t.

Bruce