Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site burl.UUCP Path: utzoo!watmath!clyde!burl!rcj From: rcj@burl.UUCP (R. Curtis Jackson) Newsgroups: net.unix-wizards Subject: long vs. int vs. short guidelines (especially for wizards!!) Message-ID: <430@burl.UUCP> Date: Thu, 5-Apr-84 20:04:44 EST Article-I.D.: burl.430 Posted: Thu Apr 5 20:04:44 1984 Date-Received: Sat, 7-Apr-84 03:13:23 EST References: <444@sri-arpa.UUCP> Organization: AT&T Technologies; Burlington, NC Lines: 42 Here are some guidelines on using int/short/long direct from both past experience and the AT&T Technologies Unix/C interfacing course I took a while back: GUIDELINE #1: DON'T EVER USE int. GUIDELINE #2: THERE IS NO GUIDELINE #2. It is very simple -- don't worry about which type is involved; just worry about how many bits you need. If you are doing heavy math, you may want to watch out for automatic conversions; they are explained in great detail in R&K p. 184 section 6.6. As for the reason not to use int, here is a rundown on three computers that I can be sure of my info on right off the bat: Number of bits short int long 3B20S 16 32 32 VAX 16 32 32 PDP 16 16 32 One excellent way to do things is to head each program or major header file (if a big software package is involved) with the following: typedef EIGHT char; typedef SIXTEEN short; typedef THIRTY2 long; or something similar. Then just tell the person porting the software to go in and do a 30-second customization of your program(s); you will have used your EIGHT, SIXTEEN, and THIRTY2 throughout so all she has to change is those three lines. I would love to see some good portability guidelines for 'C', because I get REAL tired of people who write code without (apparently) knowing about cpp(1), typedef statements, make(1), header files, etc. etc. Who, me? Throw the first stone? I must be a saint!! :-) -- The MAD Programmer -- 919-228-3313 (Cornet 291) alias: Curtis Jackson ...![ floyd clyde ihnp4 mhuxv ]!burl!rcj