From jhauser@jhauser.us Fri Feb 27 00:09:02 2004 Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by dkuug.dk (8.12.10/8.9.2) with ESMTP id i1QN8w1S082911 for ; Fri, 27 Feb 2004 00:08:59 +0100 (CET) (envelope-from jhauser@jhauser.us) Received: from cordia (c-24-7-96-152.client.comcast.net[24.7.96.152]) by comcast.net (rwcrmhc13) with ESMTP id <2004022623092101500ockpne>; Thu, 26 Feb 2004 23:09:21 +0000 From: "John Hauser" To: Embedded-C Date: Thu, 26 Feb 2004 15:10:24 -0800 MIME-Version: 1.0 Subject: Re: (embedded-c.191) TR 18037 Message-ID: <403E0C60.11341.49C57C@localhost> Priority: normal In-reply-to: <200402261936.i1QJa0Xf078873@dkuug.dk> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Spam-Score: 0 () Doug Gwyn: > The function names could be changed back to *q while the constant suffix > could be left as *k. The reason we changed away from "q" in the first place was because some systems have been using that letter to refer to quadruple-precision floating-point. The thing is, those people are _also_ already using "strtoq" for conversion to the quadruple-precision format. So, actually, there's little sense to taking the road you suggested: if we're going to conflict with the quadruple-precision people on "strtoq", we might as well conflict with them on "q" suffixes, too, and be consistent. Conversely, if we can't use "q" suffixes on constants to avoid this conflict, then we can't use "q" in the function names, either, for the same reason. What's more, it's even worse than that, because it appears the Linux people are using "q" to refer to some kind of quadruple- precision integer, not floating-point. Do a Web search for "strtoq", and you'll see what I'm talking about. I think we had the right idea the first time this came up: Change everything to a different letter. The letter "k" would have been a good choice if not for "strtok". There are still a few other letters free. I did a quick review and came up with the following, tentative, list: b m v w y Of these, I like "m" the best, because it's one of the least confusing within the function names, it seems to have very little existing use (e.g., there are very few "strtom"s and such visible on the Web), and--as Willem noted when he proposed "m" in Santa Cruz--it's the only one of the five that appears in the keyword "accum". Does anyone have a different favorite, or know of a reason why it can't be "m"? We'll want to be extra sure we get it right on our third try, right? :^) - John H.