Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!lobster!shell!shell!rjohnson From: rjohnson@shell.com (Roy Johnson) Newsgroups: comp.lang.c Subject: Re: trouble with macro`s Message-ID: Date: 21 Mar 91 16:42:53 GMT References: <15506@smoke.brl.mil> <15523@smoke.brl.mil> Sender: usenet@shell.shell.com (USENET News System) Organization: Shell Development Company, Bellaire Research Center, Houston, TX Lines: 21 In-Reply-To: gwyn@smoke.brl.mil's message of 20 Mar 91 21:21:38 GMT In article <15523@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: > That's a short-sighted attitude. We KNOW such code will quit "working" > some day. That should be sufficient reason to find a better solution > that does not depend on errors in the C implementation. Such as...? I suggested a kludge that I know works in the present. If that's all he needs, I've given him a working solution. If the code will eventually need to be recompiled (which we do not know), then the documentation should include the relatively small changes required to get it up to snuff -- and he knows what those changes are, since he needed a kludge to work around them in the present. Please explain why working with what you have, with an eye on the future is short-sighted. P.S. Thanks for clarifying my confusion on hex/oct constants. I was pretty sure about the dec-hex-oct equivalence, but not about differing bit-representations. -- ======= !{sun,psuvax1,bcm,rice,decwrl,cs.utexas.edu}!shell!rjohnson ======= Feel free to correct me, but don't preface your correction with "BZZT!" Roy Johnson, Shell Development Company