Date: Fri, 16 Jun 95 11:32:22 MDT From: terry@cs.weber.edu (Terry Lambert) To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= aka) Cc: hackers@FreeBSD.org, peter@haywire.DIALix.COM Subject: Re: penalty of using off_t for arithmatic with gcc's long Message-ID: <9506161732.AA12315@cs.weber.edu> In-Reply-To: <xQUzMulio3@astral.msk.su> from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= aka" at Jun 16, 95 03:47:42 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 1) fseek argument: it is "long" per POSIX standard. You can't > read > 2GB in POSIX enviroment in any case with 4bytes longs > using fseek. This is not true. The off_t typedef "must be an atomic type" per POSIX. Now because of calling convention, on a machine with 32 bit ints and 64 bit longs (instead of "long long", which is not an atomic type), you will continue to have stack passing problems because of the calling conventions when using an unprototyped lseek/fseek. The only real soloution is the preamble the calling conventions (like VMS or OSF/1 does). This is a terifically *ugly* fix, and must be done in the compiler. > If you include <unistd.h>, you don't need to cast lseek() argument to off_t. 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. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9506161732.AA12315>