Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!brolga!bunyip.cc.uq.oz.au!oat!qut.edu.au!lunnon
From: lunnon@qut.edu.au
Newsgroups: comp.os.minix
Subject: Re: use only short and long (not int) in struct message
Message-ID: <1991Jan10.092954.22445@qut.edu.au>
Date: 10 Jan 91 14:29:54 GMT
References: <41247@nigel.ee.udel.edu>
Organization: Queensland University of Technology
Lines: 39

In article <41247@nigel.ee.udel.edu>, HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes:
> Well, int16 int32 etc are appropriate if the different parts which
> communicate are compiled not only in 16 or 32-bit mode, but also by
> incompatible compilers.
> 
> In this case, different alignment/padding etc of structures may do
> any damage, but of course, it is more general to write int16, int32.

I agree, in my 32 bit port of the general Minix libraries so I could
compile 32 bit binaries to run under the 16 bit kernels this is a problem
however, this is easily overcome by coding the message packing routines
explicitly in assembler OR by using #pragma pack(1) and doing your own padding
I infact found a problem where the union order of the message union was
significant. Re-ordering the union elements fixed this !!!
I think you can count on consistent padding strategies in many cases there
really is only one case that has problems (ie do you put a char in the low
or high byte of the word) the solution is natural I think.

> 
> The real point is that FS must be modified to accept 'long' nbyte parameters
> for read(fd, buf, nbyte) and write(fd, buf, nbyte)
> 

I thought it already did ????    I think under C library rule nbytes is a long
or was that an ansi change ???


> It should be no problem if fd is cast to short, but nbyte should ALWAYS be
> long to support user programs with int==long.
> 
> C.v.W.


PS to support 32 bit languages some sign extending around sys calls is 
needed, In order to accept 32bit parts in the kernel I have fixed this in mpx.s


	BOB
	R.Lunnon@qut.edu.au