Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!aplcen!boingo.med.jhu.edu!haven!adm!smoke!gwyn From: gwyn@smoke.brl.mil (Doug Gwyn) Newsgroups: comp.lang.c Subject: Re: trouble with macro`s Message-ID: <15549@smoke.brl.mil> Date: 22 Mar 91 21:23:42 GMT References: <15523@smoke.brl.mil> Organization: U.S. Army Ballistic Research Laboratory, APG, MD. Lines: 26 In article rjohnson@shell.com (Roy Johnson) writes: >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...? As usual when someone asks how to do something that has no good answer, insufficient information was provided about the context for the respondent to be able to solve the REAL problem. Experienced systems analysts can attest to the fact that frequently the question actually asked is the wrong question because it already presupposes certain constraints on the answer that are not in fact necessary constraints, and the best overall solution often requires backing up to the real issue and solving that free of the unnecessary assumed constraints. I don't know why the original requestor thought he needed token pasting. I do know that in all cases where *I* have had a use for token pasting, I have also been able to find alternative solutions not involving token pasting at the C compilation level. For example, one might create a program that generates the desired C source code, using C, awk, m4, or some other existing language is a perfectly straightforward manner. >P.S. Thanks for clarifying my confusion on hex/oct constants. You're welcome -- that's what this newsgroup is for.