From jb@benito.com  Thu Feb 26 17:25:57 2004
Received: from mail.cruzio.com (mail.cruzio.com [63.249.95.37])
	by dkuug.dk (8.12.10/8.9.2) with ESMTP id i1QGPh1S074827
	for <embedded-c@dkuug.dk>; Thu, 26 Feb 2004 17:25:52 +0100 (CET)
	(envelope-from jb@benito.com)
Received: from blue (dsl2-63-249-107-101.cruzio.com [63.249.107.101])
	by mail.cruzio.com with ESMTP id i1QGQ8wS090842
	for <embedded-c@dkuug.dk>; Thu, 26 Feb 2004 08:26:09 -0800 (PST)
From: "John Benito" <jb@benito.com>
To: "'Embedded-C'" <embedded-c@dkuug.dk>
Subject: RE: (embedded-c.188) TR 18037
Date: Thu, 26 Feb 2004 08:26:11 -0800
Message-ID: <000201c3fc85$3fc7e260$6401a8c0@blue>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <200402261620.i1QGKMNA074709@dkuug.dk>
X-Spam-Score: 0.633 () LARGE_HEX

Actually, P.J. Plauger reported the bug to me, I just sent it on to
Willem.

jb -


> -----Original Message-----
> From: willemw@ace.ace.nl [mailto:willemw@ace.ace.nl] On Behalf Of
Willem
> Wakker
> Sent: Thursday, February 26, 2004 8:21 AM
> To: Embedded-C
> Subject: (embedded-c.188) TR 18037
> 
> Hi,
> 
> Two pieces of news.
> 
> The good news is that TR 18037 - Extensions for the Programming
> Language C to support embedded processors - is approved for
> publication; during the final JTC1 ballot only one No vote
> was issued (from Switzerland, to a large extend the same vote as
> during the previous ballot).
> 
> The bad news is that John Benito discovered the first genuine
> Embedded-C defect. The source of this defect is as follows:
> we have suffixes for the various fixed-point types and use
> these suffixes also to identify the return type of various functions.
> The suffix for the accum type used to be the letter 'q', but this
> was changed (based on comment UK-3, discussed and decided on in
> Santa Cruz, see n990) to 'k'. This implied that the name of the
> function to convert a string to an accum value 'strtoq' was changed
> to 'strtok', and we did not noticed that this clashes with the
> string.h function of the same name (see 7.21.5.8).
> 
> Solutions? Don't know yet.
> Possible options:
> - leave as is; this would imply that string.h and stdfix.h cannot
> be used simultaneously.
> - change the 'k' back to 'q'; a rather big change but, if done
> quickly, would not hurt too many implementations ...
> - invent a new name for this specific case ('strtokk'?): not nice
> but simple to do.
> 
> My favourite is to remove 7.21.5.8 from the standard (who would
> use this anyway?) but I don't think that this is a real option.
> 
> Suggestions? The quicker we react, the less damage is done ...
> 
> - Willem.
> 
>
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> Willem Wakker					 email: <willemw@ace.nl>
>
cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
> ACE Consulting bv				  tel: +31 20 6646416
> van Eeghenstraat 100				  fax: +31 20 6750389
> 1071 GL  Amsterdam, The Netherlands		  www: http://www.ace.nl
>
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee