Eduardo Horvath wrote:

> On Tue, 13 Jun 2000, Simon Burge wrote:
> 
> > Matt Thomas wrote:
> > 
> > > At 01:19 PM 6/13/2000 +1000, Simon Burge wrote:
> > > >Locally, I've changed the members of 'struct msgbuf' from "long" to
> > > >"int64_t" to make 'struct msgbuf' compat32 friendly.  I've not had any
> > > >problems on either alpha or i386 other than the old msgbuf looking a bit
> > > >funny on i386 - I suspect it would fail the magic test on sparc due to
> > > >endianness.
> > > 
> > > That's wrong, IMO.  If anything change them to int32_t.
> > 
> > I just tried int32_t and it works fine ok.  A 32 bit limit on the size
> > of msgbuf obviously shouldn't worry anyone...
> > 
> > > The overhead of
> > > int64 is unacceptable on many of the older platforms.
> > 
> > Do you have any figures for how a vax or m68k deals with say adding two
> > 64bit numbers?
> 
> Switching to `int' or `int32_t' is better IMHO.  I wanted to do that back
> in 1.4 but got pushback from the alpha port.  Don't know why anyone would
> want more than 4GB of message buffer anyway.

I had a quick look through the tech-kern and port-alpha archives but
couldn't find a reference to any msgbuf discussions.

So, is there (still?) anyone against using 32 bit ints inside struct
msgbuf on all ports?


Looking the other way, almost all info that gets written to the message
buffer is also dumped on the console (right?), so even on the slowest
machines incrementing a 64 bit int should be orders of magnitudes faster
than writing a byte to the console.  So this could be one application
with the speed isn't (so) important...

Simon.