Path: utzoo!attcan!uunet!decwrl!ucbvax!galileo.berkeley.edu!jbuck From: jbuck@galileo.berkeley.edu (Joe Buck) Newsgroups: comp.arch Subject: Re: RISC hard to program? (was: Moto's data predicts...) Message-ID: <37660@ucbvax.BERKELEY.EDU> Date: 19 Jul 90 22:04:48 GMT References: <3241@bnr-rsc.UUCP> <37655@ucbvax.BERKELEY.EDU> <2174@uc.msc.umn.edu> Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: jbuck@galileo.berkeley.edu (Joe Buck) Lines: 30 In article <2174@uc.msc.umn.edu>, dwm@wo.msc.umn.edu (Don Mears) writes: [ I wrote ] > >If the program, when run through lint, does not print "possible pointer > >alignment problem" except for pointer values returned by malloc, and does > >not generate any other lint messages, it will not crash when compiled on > >another architecture because of an alignment problem. > > For what it's worth here are 2 programs that pass lint and run on a 68000 > based Sun-3 and abort due to alignment errors on a SPARC Sun-4: Don then gives two programs -- the first one casts back and forth between a pointer and an int to force incorrect alignment of the pointer; the second screws around with unions, writing the union as an int and then reading it as a pointer. His second program would also crash a PDP-11. Good point, Don. Writing a union as one type and reading it as another is a non-portable operation, and lint won't complain. This type of thing should never be done without surrounding comments explaining the assumptions (for example, is the machine big-endian or little-endian? What required alignment is assumed? What is assumed about the relative sizes of data types? Etc). Casting between ints and pointers is also dangerous, as I said elsewhere in my article. Lint isn't perfect, but it's a valuable tool, and I question the professionality of Unix programmers who don't use it. -- Joe Buck jbuck@galileo.berkeley.edu {uunet,ucbvax}!galileo.berkeley.edu!jbuck