On Tue, 30 Dec 2003 14:02:13 -0800, I wrote:

>Also at:
> http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n937.pdf

The minutes for the WG14 meeting on 24-October-2003 at the Kona
resort include this comment:

  4. Rationale Editors report (Benito)

  New version of rational is ready, and published in
  'The C Standard' by BSI.  Will be published to the
  WG 14 web site in PDF

See:
:  http://std.dkuug.dk/jtc1/sc22/wg14/www/docs/n1033.htm

Anyway, I guess this means there will be yet another number
assigned (probably already is, it's just that I don't know what
it is, yet.)  I can't find the document number assigned to this
new PDF file which is supposed to have been published by Benito.
But I'm sure it will show up.  Perhaps Walter Banks can comment
about the status on this, as well as the embedded group's
activities.

Also, this seems somewhat interesting:
:  http://www.knosof.co.uk/cbook/sent1.pdf

Jon

On Tue, 30 Dec 2003 12:57:29 -0800, I wrote:

>Ah, I may have found it.  I think N937 is the
current draft
>Rationale.  They keep rolling the numbers forward in order to
>confuse me.  ;)
>
>	http://awgn.antifork.org/openbook/n937.pdf

Also at:
 http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n937.pdf

Jon

On Wed, 31 Dec 2003 07:06:37 +1000, Clyde wrote:

>On Mon, Dec 29, 2003 at 09:44:07PM -0800, Jonathan
Kirwan wrote:
>> I'm interested in the details, if you are willing to expand a
>> little on this comment.
>
>Well, for example, our PIC compiler passes the address of the variable
>argument list as a hidden parameter. It has no relation to the
>address of any other parameter. The PIC has no argument stack.

Makes sense.  Thanks!

Jon

On Mon, Dec 29, 2003 at 09:50:29PM -0800, Jonathan Kirwan wrote:
> Does this suggest that the example is drawn from
code actually
> compiled on some compiler, though?  And if so, does strict

Perhaps.

> conformance to the standard mean that code like
this, perhaps
> found in the "real world", will break?  Do compiler vendors

It's certainly possible.

> concern themselves with breaking existing code
despite the
> standards suggesting that they are allowed to do so?  Or in

It depends. In this case, my opinion would be no. There are other
cases where it is clearly appropriate to go beyond what is required
by the standard, e.g. the maximum allowed length of a line after
all macro expansions is something like 512 or 1024, but lots of
real world applications need more. Similarly with length of variable
names - the standard only requires that 31 characters be significant,
but some applications (in particular machine-generated C code) need
more. For that particular issue we provide an option to set the
number of significant characters, but 31 is the default.

-- 
Clyde Stubbs                     |            HI-TECH Software
Email: clyde@clyd...          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger clyde@clyd...   | AUS: +61 7 3552 7777 +61 7 3552 7778
---
HI-TECH C: compiling the real world.

On Mon, Dec 29, 2003 at 09:44:07PM -0800, Jonathan Kirwan wrote:
> I'm interested in the details, if you are
willing to expand a
> little on this comment.

Well, for example, our PIC compiler passes the address of the variable
argument list as a hidden parameter. It has no relation to the
address of any other parameter. The PIC has no argument stack.

Clyde

-- 
Clyde Stubbs                     |            HI-TECH Software
Email: clyde@clyd...          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger clyde@clyd...   | AUS: +61 7 3552 7777 +61 7 3552 7778
---
HI-TECH C: compiling the real world.

On Tue, 30 Dec 2003 12:29:00 -0800, I wrote:

>On Tue, 30 Dec 2003 11:42:24 -0800, I wrote:
>
>>Latest Draft Rationale (revision 2) that I have:
>>:  http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n897.pdf
>>As far as I'm aware, this is a _draft_ of the Rationale for the
>>ISO/IEC 9899:1999 C Standard.  But it may be the actual
>>Rationale, too.  I just don't know.
>
>Whoops!  This may be the Rationale for C9X and, if I understand
>what's written (I may not), that's the C95 standard (C90 + TCOR1
>+ TCOR2 + AMD1) and not for the 1999 standard.
>
>Jon

Ah, I may have found it.  I think N937 is the current draft
Rationale.  They keep rolling the numbers forward in order to
confuse me.  ;)

	http://awgn.antifork.org/openbook/n937.pdf

Jon

On Tue, 30 Dec 2003 11:42:24 -0800, I wrote:

>Latest Draft Rationale (revision 2) that I have:
>:  http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n897.pdf
>As far as I'm aware, this is a _draft_ of the Rationale for the
>ISO/IEC 9899:1999 C Standard.  But it may be the actual
>Rationale, too.  I just don't know.

Whoops!  This may be the Rationale for C9X and, if I understand
what's written (I may not), that's the C95 standard (C90 + TCOR1
+ TCOR2 + AMD1) and not for the 1999 standard.

Jon

On Tue, 30 Dec 2003 14:23:12 -0000, you wrote:

>Wolfgang,
>
>> > > On Tue, Dec 30, 2003 at 12:55:42AM -0000, Wolfgang Reich
wrote:
>> > > > Yes, in any implementation I've seen, the caller
stores the
>> > > > "placeholder" c and all ... parameters on the
stack.
>> > > 
>> > > It's not actually necessary to pass the placeholder on
the stack. 
>> > > It's often done that way (and the ANSI va_start() macro
requires 
>> > > the placeholder as an argument) but there are other ways.
>> > 
>> > Agreed.  Our placeholder is not (in general) passed on the stack,
>> it's
>> > treated as a standard parameter like any other.  We have an
>> intrinsic
>> > function that delivers the base of the variadic part of a
function.
>> 
>> And this intrinsic function doesn't need any argument, yes?
>
>Correct.
>
>> So the argument passed to va_start() is simply ignored?
>
>paramN is ignored.  paramN is required is for old-style compilers based
>on Johnson's pcc, IMO.
>
>> If this is so, then Jon's example program
>> http://groups.yahoo.com/group/msp430/message/6370 will work.
>
>Correct, although it is an erroneous program by the standard.  The
>correction doesn't appear in TC1 either.

Just for those who may be interested, I tracked down a few bits
and pieces which may help out.  The following PDF files are
available:

Latest Draft for ISO/IEC 9899:1999 C Standard:
:  http://std.dkuug.dk/jtc1/sc22/open/n2794/n2794.pdf
This is __NOT__ the final standard, which must be purchased.
But it's the last draft that was made available to the public; I
believe this is a copy of what was available prior to the final
standard being released.  The purchased version of the PDF also
includes a convenient set of bookmarks -- so that's one way to
tell what you've got in hand.

Latest Draft Rationale (revision 2) that I have:
:  http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n897.pdf
As far as I'm aware, this is a _draft_ of the Rationale for the
ISO/IEC 9899:1999 C Standard.  But it may be the actual
Rationale, too.  I just don't know.

Full Technical Corrigendum 1 for the 1999 C standard:
: 
http://ftp2.ansi.org/download/free_download.asp?document=ISO%2FIEC+9899%2FCor1%3A2001
This is, so far as I'm aware, the actual and official version of
the Technical Corrigendum 1 for ISO/IEC 9899:1999 C Standard.  I
believe WG14 held a vote on making this one available to the
public and approved that proposal some time ago.

A draft of the "Extensions for the programming language C to
support embedded processors":
:  http://anubis.dkuug.dk/JTC1/SC22/WG14/www/docs/n1021.pdf
This is from JTC1 NP 18037, Extensions for the programming
language C to support embedded processors, whose project
director is Willem Wakker, I believe.

Just for information.

Jon

Wolfgang,

> > > On Tue, Dec 30, 2003 at 12:55:42AM
-0000, Wolfgang Reich wrote:
> > > > Yes, in any implementation I've seen, the caller stores
the
> > > > "placeholder" c and all ... parameters on the
stack.
> > > 
> > > It's not actually necessary to pass the placeholder on the
stack. 
> > > It's often done that way (and the ANSI va_start() macro
requires 
> > > the placeholder as an argument) but there are other ways.
> > 
> > Agreed.  Our placeholder is not (in general) passed on the stack,
> it's
> > treated as a standard parameter like any other.  We have an
> intrinsic
> > function that delivers the base of the variadic part of a function.
> 
> And this intrinsic function doesn't need any argument, yes?

Correct.

> So the argument passed to va_start() is simply
ignored?

paramN is ignored.  paramN is required is for old-style compilers based
on Johnson's pcc, IMO.

> If this is so, then Jon's example program
> http://groups.yahoo.com/group/msp430/message/6370 will work.

Correct, although it is an erroneous program by the standard.  The
correction doesn't appear in TC1 either.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk CrossWorks
for MSP430 and ARM processors

Beginning Microcontrollers with the MSP430