From jhauser@jhauser.us Tue Mar 9 07:25:55 2004 Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by dkuug.dk (8.12.10/8.9.2) with ESMTP id i296Pdea058180 for ; Tue, 9 Mar 2004 07:25:52 +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 (sccrmhc12) with ESMTP id <2004030906253501200ir182e>; Tue, 9 Mar 2004 06:25:35 +0000 From: "John Hauser" To: Embedded-C Date: Mon, 08 Mar 2004 22:27:10 -0800 MIME-Version: 1.0 Subject: strtok problem Message-ID: <404CF33E.13156.26BAA0F@localhost> Priority: normal In-reply-to: <200402262353.i1QNrJtU083838@dkuug.dk> References: <200402262309.i1QN93BN082923@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 () Sounds like I'm the only person working on this. Anyway, you may recall I originally listed five possible replacements for "k": b m v w y I mentioned earlier that "%m" is (or has been) used as a format specifier by the GNU libc (glibc). As for the others, I think "b" is a very poor choice because of the easy confusion with "bit" or "byte". For instance, a lot of people think it should be possible to write binary literals like "0b1101"; but if we pick "b", then "0b" will mean something else entirely. Also, we'd have functions such as "bbits" (reinterpret cast from integer to accum), which seems strange to me. Similarly, I see "w" as often meaning "word", and "v" as often meaning "vector". That leaves "y". I did a lot of searching using Google, and I couldn't find any significant conflicts for "y", either as a literal suffix ("0.5y"), or as a format for scanf and printf ("%y"), or as a prefix/suffix for our function names. With "y", the complete set of function names for accum types would be muliy mulily diviy divily ydivi lydivi idivy idivly muliuy muliuly diviuy diviuly uydivi ulydivi idivuy idivuly abshy absy absly roundhy roundy roundly rounduhy rounduy rounduly countlshy countlsy countlsly countlsuhy countlsuy countlsuly bitshy bitsy bitsly bitsuhy bitsuy bitsuly hybits ybits lybits uhybits uybits ulybits strtohy strtoy strtoly strtouhy strtouy strtouly Some might call this ug-ly. Still, none of these particular names has an existing constituency as far as I can find. On the other hand, I have to wonder whether the "ly" suffix won't cause trouble for constructing other function names down the road. So there you have it. In my opinion, we have three options: 1) Go back to using "q" and fight it out with the quadruple-precision floating-point people. 2) Change all our "strto" functions to "strto_"; that is, "strtok" becomes "strto_k", "strtohr" becomes "strto_hr", etc. This is probably the easiest solution, but it's also a little inconsistent with the rest of the C library. 3) Switch to using "y". Believe it or not, I don't think I have a strong preference among the three, other than to suggest that option 1 might not be viable. Anybody want to voice an opinion? - John Hauser