From walter@bytecraft.com Tue Mar 9 14:46:26 2004 Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by dkuug.dk (8.12.10/8.9.2) with ESMTP id i29DkCea062803 for ; Tue, 9 Mar 2004 14:46:18 +0100 (CET) (envelope-from walter@bytecraft.com) Received: from granite.sentex.ca (granite-64.sentex.ca [64.7.153.1]) by smtp3.sentex.ca (8.12.10/8.12.10) with ESMTP id i29DkBOp035898; Tue, 9 Mar 2004 08:46:11 -0500 (EST) (envelope-from walter@bytecraft.com) Received: from bytecraft.com (p138xjl1ll.dsl2.sentex.ca [64.7.159.140]) by granite.sentex.ca (8.12.10/8.12.10) with ESMTP id i29Dk0fp068756; Tue, 9 Mar 2004 08:46:12 -0500 (EST) (envelope-from walter@bytecraft.com) Message-ID: <404DC902.D37D6100@bytecraft.com> Date: Tue, 09 Mar 2004 08:39:14 -0500 From: Walter Banks X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Hauser CC: Embedded-C Subject: Re: (embedded-c.200) strtok problem References: <200402262309.i1QN93BN082923@dkuug.dk> <200403090625.i296PuOU058190@dkuug.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () Good investigation. We might be already too late to make this change. (I know that doesn't resolve the name conflict) I may have missed something on this but if all we have is a single library name conflict it might less impact on developers and compiler implementations to resolve the name conflict. We are starting to see a user base out there with application code. Either way we don't have much time. w.. John Hauser wrote: > > 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