Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!nrl-cmf!ukma!xanth!mcnc!ece-csc!ncrcae!ncrlnk!uunet!munnari!murtoa.cs.mu.oz.au!wcc!latcs1!ditmela!yarra!melba!gnb From: gnb@melba.bby.oz (Gregory N. Bond) Newsgroups: comp.arch Subject: Re: Endian wars Message-ID: <100@melba.oz> Date: 9 Feb 89 02:59:15 GMT References: <6133@columbia.edu> <3300050@m.cs.uiuc.edu> <8480@aw.sei.cmu.edu> Organization: Burdett, Buckeridge & Young Ltd, Melbourne Lines: 29 Reply-To: In article <8480@aw.sei.cmu.edu> firth@bd.sei.cmu.edu (Robert Firth) writes: [ Re: while (*p++ = *q++); ] .This is a neat and beautiful idiom in PDP-11 Assembler. There is, .however, one problem with the equivalent C code: it is incorrect. .After termination of the loop, the variables p and q, though declared .of type 'pointer-to-char', will hold values that do not point to .declared or allocated objects of type 'char'. Should you ever have .the misfortune to port this code to a machine with hardware segmentation, .and automatic segment bounds checking as part of the address arithmetic, .(or be a consultant involved in such a port), you will face this .problem. . .Could someone inform me whether the current C standard has fixed this? .The simplest answer I guess is to rule that the address of array[upb+1] .must always be legal; in practice this means the implementation has to .leave dead space at the end of each memory segment. This is only a problem if p or q are dereferenced after the loop. They are (at least potentially) invalid addresses, but so is NULL. And if it is legal for p to be NULL, it is legal for it to point nowhere. And if it is dereferenced, SIGSEGV it, just as with NULL pointers. No need to fix the ANSI doc, nor to allocate dead space. It's not incorrect (IMHO!) [ No, we don't have comp.lang.c in Australia. Sorry. ] -- Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia Internet: gnb@melba.bby.oz.au non-MX: gnb%melba.bby.oz@uunet.uu.net Uucp: {uunet,mnetor,pyramid,ubc-vision,ukc,mcvax,...}!munnari!melba.bby.oz!gnb