Date: Sat, 17 Jun 1995 13:58:16 +1000 From: Bruce Evans <bde@zeta.org.au> To: ache@astral.msk.su, terry@cs.weber.edu Cc: hackers@freebsd.org, peter@haywire.DIALix.COM Subject: Re: penalty of using off_t for arithmatic with gcc's long Message-ID: <199506170358.NAA12478@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506170358.NAA12478>