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: <1991Jan9.155156.22395@qut.edu.au> Date: 9 Jan 91 20:51:56 GMT References: <41145@nigel.ee.udel.edu> Organization: Queensland University of Technology Lines: 37 In article <41145@nigel.ee.udel.edu>, burgess%creek.decnet@hqhsd.brooks.af.mil (CREEK::BURGESS) writes: > Klamer Schutte -- Universiteit Twente writes: >> >>HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: >> >>>If struct messages contains only short and long (no 'int'), >>>various parts of the system (user code, FS, MM, Kernel etc) can >>>communicate irrespective of wether they are compiled in 16-bit or >>>32-bit mode. >> >>Why include the assumption that short == 16 bits and long == 32 bits? >>Please use something like int16 and int32 when you mean that. >>This will save you when using a machine where short=16, int=32 and long=64 bits >> >>These names should be typedef'ed somewhere. >> >>Comments? > Wasn't the original definition of "short" and "long" from K&R explicit? I > recall a page in the book describing the various lengths of the the types and > "int" being the only machine-specific one. I think the definition was > short: 8 bits and long: [16||32) i can't remember exactly)] bits. Besides, > the compilers in question are virtually all written by and maintained by > people on the net. If short is always eight bits and long is always 32 bits, > then the idea (IMHO) is an excellent method to overcome the problems with > variant "int" sizes. Yes, This would work UNTILL a 64 bit long compiler comes alomg :-( I vote for int16 and int32 BOB > > TSgt Dave Burgess > Armstrong Labs Det 4 > Brooks AFB, TX