Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!kddlab!titcca!sragwa!wsgw!socslgw!diamond
From: diamond@csl.sony.co.jp (Norman Diamond)
Newsgroups: comp.std.c
Subject: Re: Re: Re^3 (was 2): struct comparison
Message-ID: <10606@riks.csl.sony.co.jp>
Date: 26 Jul 89 02:08:52 GMT
References: <167@ssp1.idca.tds.philips.nl> <12040019@hpfcdc.HP.COM>
Reply-To: diamond@riks. (Norman Diamond)
Organization: Sony Computer Science Laboratory Inc., Tokyo, Japan
Lines: 24

In article <12040019@hpfcdc.HP.COM> donn@hpfcdc.HP.COM (Donn Terry) writes:

>(Something has to give with off_t, and soon; 4Gb disks are coming along
>very soon.   It would be nice to find a way to deal with them without
>having to rewrite every use of off_t and lseek() in the world.

It is time to learn a lesson from the 80*86 family.  Near and far are
kluges.  It is a pain in the *** to be unable to do pointer arithmetic
in a reasonable fashion.

The lesson?  Integral types and off_t will be kluges.  It will be a pain
in the *** to be unable to do off_t arithmetic in a reasonable fashion.

Any vendor who supplies 4Gb disks should supply a long long type in
their C compilers.  Quality of implementation issues should encourage
this semi-portable extension.  This will save many pains in the ***.
If the marketplace allows this to occur, then C-0X will standardize it.

--
-- 
Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net)
  The above opinions are inherited by your machine's init process (pid 1),
  after being disowned and orphaned.  However, if you see this at Waterloo or
  Anterior, then their administrators must have approved of these opinions.