Proposal

Proposal

[Frank Klemm]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6778 bytes --]

I propose a websites with the following contents:

  - gcc language extentions
  - possible performance enhancements 2)
  - warnings of the compiler  3)
  - libc related issues

  - gcc language extentions (future)  1)
  - possible performance enhancements (future)
  - warnings of the compiler (future)  
  - libc related issues (future)

  - gcc language extentions (decline)
  - possible performance enhancements (decline)
  - warnings of the compiler (decline)
  - libc related issues (decline)

  
Every proposal is discussed in the mailing list and is classified into:

  - should be done in the next time
  - future improvement, useful, but too difficult to implement in the next time
  - decline, not so useful, too many problems, too difficult to implement
  
  - gcc language extentions: Extention of the language C or C++
  - where are performance improvements possible
  - additional or superfluous warnings (or errors)
  - libc related issues, missing library function, problems,
    bugs and flaws


Performance test suite

  - list of small *.inc files containing a small piece of code  4)
  - a body function which does all the rest
  - a table for the Duron/Athlon family, for the PII/PIII/Celeron family and
    one for the P4 family
  - a table for -O, -O2 and for -O3
  - task is to show improvements and deterioration in the compilers code


Test#  Description                    operations/µs
                                2.95.2  3.00    3.01    3.02
-------------------------------------------------------------
 137  round test (int)floor()   11.5    11.9    11.8    191
 138  foobar                    91      75      75      92








1) ******************************************************************************

Separator for long number
~~~~~~~~~~~~~~~~~~~~~~~~~

The bigger the number the more difficult is it to decipher large numbers:

    0xFFFFFFFFFFFFFFFC
    1000000000000
    0x0FFFFFFFFFFFFFFC
    10000000000000
    3.14159265358979
    12768487.0

Ada 83 and Ada 95 allows '_' in numbers to separate groups of numbers:

    0xFFFF_FFFF_FFFF_FFFC
    1_000_000_000_000
    0x0FFF_FFFF_FFFF_FFFC
    10_000_000_000_000
    3.14159_26535_8979
    12_768_487.0
    
The '_' is allowed at every position between digits, but it is recommend to use 
it in the way above.

  integral hexadecimal numbers:		4 digits
  decimal integral part of numbers:	3 digits
  fractional part of numbers:		5 digits

May be we should introduce this is C too.

It is not allowed to compose numbers with '_' inside of macros.

  #define MILLION	_MERGE5 ( 1, _, 000, _, 000 )

This allows easily to write a filter to generate C89 or C99 files.
    

Problems
~~~~~~~~

The are no problems with foreward compatibilty, syntax always generates a syntax error on standard C99 compilers.
Programs are not backward compatible at all.

gcc should contain a filter to convert files with '_' inside of numbers into
C89 or C99 files.

    gcc -_ program.c > filtered/program.c


Pros
~~~~

It makes C and C++ programs easier to read
It is easier to find errors.


Cons
~~~~

Bad backward compatibility.
There are other writing possible:

  1000000000000      = 1_000_000_000_000     = 1000 * 1000 * 1000 * 1000
  0xFFFFFFFFFFFFFF00 = 0xFFFF_FFFF_FFFF_FF00 = ~0x100
  
But it is easy to introduce other bugs with these writings




2 ****************************************************************************

Command line ----------------------------------------

gcc302 -O3 -fomit-frame-pointer

C code ----------------------------------------------

unsigned long long x;

void
main ( void )
{
    x >>= 32;
    return 0;
}

Assembler code ---------------------------------------

main:	pushl	%ebp		<------
	movl	%esp, %ebp	<------
	subl	$8, %esp	<------
	movl	x+4, %eax
	xorl	%edx, %edx
	andl	$-16, %esp	<------
	movl	%edx, x+4
	movl	%eax, x
	movl	%ebp, %esp	<------
	xorl	%eax, %eax
	popl	%ebp		<------
	ret


Suggested optimized Assembler code: ------------------------------

// -O2
main:	movl	x+4, %eax
	xorl	%edx, %edx
	movl	%eax, x
	movl	%edx, x+4
	xorl	%eax, %eax
	ret
	
// -Os	
main:	movl	$x, %ecx
	xorl	%edx, %edx
	movl	4(%ecx), %eax
	movl	%edx, 4(%ecx)
	movl	%eax,  (%ecx)
	xorl	%eax, %eax
	ret

// -Oss
main:	movl	$x+4, %ecx
	xorl	%eax, %eax
	movl	(%ecx), %edx
	movl	%eax, (%ecx)
	movl	%edx, -4(%ecx)
	ret

Current version: 33 byte
proposed -O2:    21 byte
proposed -Os:    18 byte
proposed -Oss:   15 byte


Remarks ----------------------------------------------

Stack alignment of gcc 3.02 is really a nasty thing.
It blows up code, it slows down code. It is really a pain.

Before doing alignment on stack there should be clarified:

  - who is responsable for aligning (caller / called)
  - when it have a chance to speed up code (you need at least 64 bit items)
  - what other conditions are needed to speed up code
    (manipulating %esp decreases speed of push/pop/mov)


Proposal ------------------------------------------------

  - A caller should never align the stack
  - A function aligns the stack if there are arrays of 64 bit local
    variables on the stack
  - If there are many 64 bit local variables on stack the function may align
    the stack
  - functions arguments can be copied to such a local place if the variable
    is often used and not copied to a FPU register.

3 ***************************************************************


Problem
~~~~~~~

Using of operator <=, >= or != although only one of the two partial conditions
is possible:

   unsigned int  x;
   if ( x <= 0 ) {
       ...
   }

   unsigned char  c;
   if ( c != 255 ) {
       ...
   }

This is often a hint that the code is wrong.
It should be possible to genarte a warning for such code.


4 *******************************************************************

/*
 *  Rounding floats to integers, always rounding to -inf.
 */

/* Argument is the ca. execution time on a 1 GHz computer in milliseconds */

float  test0137_float [1000];
int    test0137_int   [1000];

struct result
test0137_run ( unsigned int  ms )
{
    struct result  ret;
    unsigned int   i;
    unsigned int   j;
    unsigned int   k;

    for ( k = 0; k < ms; k++ )
        for ( i = 0; i < 200000; i++ )
            for ( j = 0; j < 1000; j++ )
                test0137_int [j] = (int) floor (test0137_float [j]);

    ret.name = "round test (int)floor()";
    ret.ops  = 200.e6 * ms;
    return ret;
}

void
test0137_init ( void )
{
}

/* The rest will be done by the program around */


-- 
Mit freundlichen Grüßen
Frank Klemm
 
eMail | pfk@uni-jena.de       home: pfk@schnecke.offl.uni-jena.de
      | fingerprint: CDBB D7AE 0488 96B2  E0F9 98C2 1441 051C
phone | +49 (3641) 64-2721    home: +49 (3641) 390545
sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany

Re: Proposal

[Gerald Pfeifer]

On Sat, 15 Sep 2001, Frank Klemm wrote:
>   - libc related issues

libc related issue are (far) beyond the scope of GCC, as far as I can
see.

> Performance test suite
>
>   - list of small *.inc files containing a small piece of code  4)
>   - a body function which does all the rest
>   - a table for the Duron/Athlon family, for the PII/PIII/Celeron family and
>     one for the P4 family
>   - a table for -O, -O2 and for -O3
>   - task is to show improvements and deterioration in the compilers code

That's definitely worthwhile. Marc already started working on something
like this some time ago, it would be nice to unite both efforts.

Though, this should not be limited to ia32 processors, as per your
suggestion.

Geraldy
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Proposal

[Neil Booth]

Frank Klemm wrote:-

> Ada 83 and Ada 95 allows '_' in numbers to separate groups of numbers:
> 
>     0xFFFF_FFFF_FFFF_FFFC
>     1_000_000_000_000
>     0x0FFF_FFFF_FFFF_FFFC
>     10_000_000_000_000
>     3.14159_26535_8979
>     12_768_487.0
>     
> The '_' is allowed at every position between digits, but it is recommend to use 
> it in the way above.

This is possibly a good idea.  It's a trivial patch to implement it
(c-lex.c I think, unless Zack finally applies his number patch); a
comment even exists in the code mentioning that it might be a future
extension.

> It is not allowed to compose numbers with '_' inside of macros.
> 
>   #define MILLION	_MERGE5 ( 1, _, 000, _, 000 )
> 
> This allows easily to write a filter to generate C89 or C99 files.

I don't understand quite what you're saying here.  If you're saying
dissallow concatenation with ## then I would strenuously object, since

1) disallowing it seems gratuitous,
2) it's specifically allowed by the standard, and
3) it would be introducing yet more special cases to the preprocessor,
   which already has too many of those for my liking.

Neil.

Re: Proposal

[Joseph S. Myers]

On Mon, 17 Sep 2001, Neil Booth wrote:

> This is possibly a good idea.  It's a trivial patch to implement it
> (c-lex.c I think, unless Zack finally applies his number patch); a
> comment even exists in the code mentioning that it might be a future
> extension.

However, we shouldn't add it to GCC yet.  Since this feature would not
actually allow you to do something that couldn't reasonably be done before
or make it substantially simpler to do so, and since it might be
appropriate for a future version of the standard, a more appropriate
procedure would be:

* Create a patch for GCC, and the exact proposed changes to the text of
C99.  (The patch is desirable here to show implementation experience.)

* Iterate with comp.std.c about the exact semantics and the desirability
of the feature.

* In due course, when the time comes for adding new language features to
the C standard (so not for a few years yet), propose it via your National
Body for inclusion in C0X.

* Once it is in a C0X draft, then addition to GCC as part of tracking C0X
drafts (with a strong warning that any features added as part of C0X
tracking may be removed or changed without notice to keep up with changing
drafts) would be appropriate.

History shows that extensions tend to cause problems, so we should be wary
of adding it until it is in a C0X draft.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Proposal

[Zack Weinberg]

On Tue, Sep 18, 2001 at 10:28:50AM +0100, Joseph S. Myers wrote:
> On Mon, 17 Sep 2001, Neil Booth wrote:
> 
> > This is possibly a good idea.  It's a trivial patch to implement it
> > (c-lex.c I think, unless Zack finally applies his number patch); a
> > comment even exists in the code mentioning that it might be a future
> > extension.
> 
> However, we shouldn't add it to GCC yet.  Since this feature would not
> actually allow you to do something that couldn't reasonably be done before
> or make it substantially simpler to do so, and since it might be
> appropriate for a future version of the standard, a more appropriate
> procedure would be:
[snip]

I can tell you exactly what comp.std.c will say: Go away, implement
it, and get several years of experience with the extension, then come
back with a formal proposal.  The suggested extension (_ as a
separator in numbers) was actually proposed on comp.std.c just before
C99 was finalized, and they said just that.

We have also been around this particular wheel with other extensions.
Does anyone remember __norestrict?  Your recipe is equivalent in
practice to "we will add no (more) extensions, ever."  Which is a
legitimate position to take, but only by coming out and saying so.  It
is unfair to run people through a lengthy bureaucratic procedure that
appears to offer the possibility of adding an extension, but will
always result in the extension being rejected.

I'd also point out that very few people have access to the standard;
yes, ANSI sells copies for not-totally-outrageous sums, but many don't
know that and the cost may still be too high.

Counterproposal: Require people who propose extensions to document
their semantics in detail, to the point where a formal proposal
_could_ be made to the standard committee, but don't make them get
beaten up by comp.std.c.  Debate the extension here and in the user
community.  If there's agreement that it would be useful, it would not
clash with present or future standard behavior, and it would not cause
unfortunate consequences down the road, then we implement it.

For all extensions, present or proposed, we either write up a formal
proposal to the standard committee, or we deprecate the extension.
The proposals are stored on the website.  Should we ever be in the
position of having representation on the committee (which I believe we
currently do not) we can then submit them.

zw

Re: Proposal

[Joseph S. Myers]

On Tue, 18 Sep 2001, Zack Weinberg wrote:

> I can tell you exactly what comp.std.c will say: Go away, implement
> it, and get several years of experience with the extension, then come
> back with a formal proposal.  The suggested extension (_ as a
> separator in numbers) was actually proposed on comp.std.c just before
> C99 was finalized, and they said just that.

Just before C99 was finalized wasn't an appropriate time for proposing new
features; nor is now (too soon until at least the standard is more widely
implemented; even then it may be some time before consideration of major
new features is appropriate (the UK National Body has agreed a position
(written by Nick Maclaren) that destabilising changes should be avoided
until there is industry consensus on the interpretation of C99 (readers of
comp.std.c will be familiar with his views of the problems in various
areas of C)), though at least this extension is comparatively harmless in
terms of interactions with others); when the time comes for C0X it should
be better publicised and more attention should be paid to comp.std.c (the
UK National Body has recently submitted 33 Defect Reports to WG14 (to add
to the 36 already registered and present on the WG14 web site), most of
them originating in problems reported to or discussed on comp.std.c).

> We have also been around this particular wheel with other extensions.
> Does anyone remember __norestrict?  Your recipe is equivalent in
> practice to "we will add no (more) extensions, ever."  Which is a
> legitimate position to take, but only by coming out and saying so.  It
> is unfair to run people through a lengthy bureaucratic procedure that
> appears to offer the possibility of adding an extension, but will
> always result in the extension being rejected.

The presumption must be against extensions because of the bad history of
problems caused by extensions that are poorly defined or later cause
problems in their interaction with new language features.  I included the
qualifications about "something that couldn't reasonably be done before"
and "might be appropriate for a future version of the standard" since
plenty of extensions are firmly within what is undefined in the standards,
e.g. asm, and others may reach the barrier of "couldn't reasonably be done
before" to justify them against the risk of future problems.  Another
qualification would be that new instances of existing extensions aren't
problematic (e.g. new built-in functions, new attributes).

> I'd also point out that very few people have access to the standard;
> yes, ANSI sells copies for not-totally-outrageous sums, but many don't
> know that and the cost may still be too high.

There is work in progress towards getting it published as a normal book
(officially, not with value-subtracting annotations by Schildt) by a
normal publisher whose books appear in bookshops.  (I don't have any more
information about these plans.)

> For all extensions, present or proposed, we either write up a formal
> proposal to the standard committee, or we deprecate the extension.
> The proposals are stored on the website.  Should we ever be in the

The proposals should be in the manual proper.  We should sort out the
manual assignment situation
(<URL: http://gcc.gnu.org/ml/gcc/2000-11/msg00753.html > and
<URL: http://gcc.gnu.org/ml/gcc/2000-11/msg00872.html >), and preferably get
a special assignment for such proposals that doesn't include the licence
grantback of the normal assignments (so that ISO have to negotiate with
the FSF alone about the inclusion of such text in the standard, and this
can be used as leverage to try to free the standard).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Proposal

[Zack Weinberg]

On Tue, Sep 18, 2001 at 07:12:21PM +0100, Joseph S. Myers wrote:
> On Tue, 18 Sep 2001, Zack Weinberg wrote:
> 
> > I can tell you exactly what comp.std.c will say: Go away, implement
> > it, and get several years of experience with the extension, then come
> > back with a formal proposal.  The suggested extension (_ as a
> > separator in numbers) was actually proposed on comp.std.c just before
> > C99 was finalized, and they said just that.
> 
> Just before C99 was finalized wasn't an appropriate time for proposing new
> features; nor is now

Right - which is precisely why we *shouldn't* make proposers of
extensions run the gauntlet of comp.std.c or the WG14 reflector.

I would like to see us in a position to propose a set of useful
improvements to the standard in the next cycle, and that means
experimenting - both with our existing extensions and with new
ones.

I'm glad to hear the UK National Body is working on the existing
issues with the C standard, but that really doesn't affect the
original poster's proposal, which is about as independent of the
existing problems as you can get.  Which isn't to say that it is
perfect - I have concerns, though I like the idea in principle.
(see other message)

> > We have also been around this particular wheel with other extensions.
> > Does anyone remember __norestrict?  Your recipe is equivalent in
> > practice to "we will add no (more) extensions, ever."  Which is a
> > legitimate position to take, but only by coming out and saying so.  It
> > is unfair to run people through a lengthy bureaucratic procedure that
> > appears to offer the possibility of adding an extension, but will
> > always result in the extension being rejected.
> 
> The presumption must be against extensions because of the bad history of
> problems caused by extensions that are poorly defined or later cause
> problems in their interaction with new language features.

Certainly the presumption is against them, and in fact I think a
position of "no additional extensions at all" is extreme but
reasonable.  What I object to is your proposed procedure, which
_appears_ to be open to new extensions, but in practice is closed, and
will subject the proposers of extensions to a great deal of wasted
effort.  Again, remember __norestrict?

> > I'd also point out that very few people have access to the standard;
> > yes, ANSI sells copies for not-totally-outrageous sums, but many don't
> > know that and the cost may still be too high.
> 
> There is work in progress towards getting it published as a normal book
> (officially, not with value-subtracting annotations by Schildt) by a
> normal publisher whose books appear in bookshops.  (I don't have any more
> information about these plans.)

Oh good.

> > For all extensions, present or proposed, we either write up a formal
> > proposal to the standard committee, or we deprecate the extension.
> > The proposals are stored on the website.  Should we ever be in the
> 
> The proposals should be in the manual proper.

I'm not sure of this; would they be useful to normal users of GCC?
Standardization proposals tend to be written in standardese and
therefore are not suitable as end-user documentation.

Keep 'em in the tree, sure.

...
> (so that ISO have to negotiate with the FSF alone about the
> inclusion of such text in the standard, and this can be used as
> leverage to try to free the standard).

I don't think we should do that, it is likely to be counterproductive.
(I.e. I suspect the response would be to reject the proposals rather
than deal with the legal issues.)  Efforts to make the standard freely
distributable are laudable but should happen independently.

zw

Re: Proposal

[Joseph S. Myers]

On Tue, 18 Sep 2001, Zack Weinberg wrote:

> I'm not sure of this; would they be useful to normal users of GCC?
> Standardization proposals tend to be written in standardese and
> therefore are not suitable as end-user documentation.

They're just as suitable as the standards themselves are - and the
standards themselves *ought* to be being used for reference by every
serious programmer in standardised languages.  (Though this doesn't remove
the use of existing tutorial material in the manual and of bodies of code
with idiomatic uses of the extensions for users to read and learn from;
nor do I claim that the optimal method for all users of *learning* C or
C++ is to read ISO 9899 or ISO 14882.)  Of course the proposals would
include the rationale for the changes as well as the actual textual
changes to the standard.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Proposal

[Frank Klemm]

On Tue, Sep 18, 2001 at 10:20:00AM -0700, Zack Weinberg wrote:
> 
> I'd also point out that very few people have access to the standard;
> yes, ANSI sells copies for not-totally-outrageous sums, but many don't
> know that and the cost may still be too high.
> 
Most programmers don't know the standard and are not interested in knowing
the standard, because their (present) job is to solve a problem for one or
two different systems, not for every theoretically possible system,
and the standard supports nearly every stuff which has more than 4 pins ;-)

Programming portable, especially with C, takes much more time than
programming for a special system, and the programmers don't have this time.
And some kins of problems are not supported by C, so you must write it in a
sub assembler language way.


> Counterproposal: Require people who propose extensions to document
> their semantics in detail, to the point where a formal proposal
> _could_ be made to the standard committee, but don't make them get
> beaten up by comp.std.c.  Debate the extension here and in the user
> community.  If there's agreement that it would be useful, it would not
> clash with present or future standard behavior, and it would not cause
> unfortunate consequences down the road, then we implement it.
> 
> For all extensions, present or proposed, we either write up a formal
> proposal to the standard committee, or we deprecate the extension.
> The proposals are stored on the website.  Should we ever be in the
> position of having representation on the committee (which I believe we
> currently do not) we can then submit them.
> 
I'm looking for some webspace for feature proposals, performance issues and warning
issues. 

And someone who translates my "pseudo English" into "real English".

  - 1 Mbyte for HTML
  - 5 Mbyte for tables
  - a link to this page

-- 
Frank Klemm

Re: Proposal

[Zack Weinberg]

On Tue, Sep 18, 2001 at 09:12:31PM +0200, Frank Klemm wrote:
> On Tue, Sep 18, 2001 at 10:20:00AM -0700, Zack Weinberg wrote:
> > 
> > I'd also point out that very few people have access to the
> > standard; yes, ANSI sells copies for not-totally-outrageous sums,
> > but many don't know that and the cost may still be too high.
>
> Most programmers don't know the standard and are not interested in
> knowing the standard, because their (present) job is to solve a
> problem for one or two different systems, not for every
> theoretically possible system, and the standard supports nearly
> every stuff which has more than 4 pins ;-)

We tend to see things differently from most programmers, since we are
responsible for supporting every feature of the compiler.  The
standard is the only thing that tells us what the compiler is supposed
to do, and we have enough trouble with its own ambiguities.  Every
extension adds ambiguities to that.

We are therefore concerned that extensions fit well with the standard,
The best way to ensure that is for the people who propose and
implement them to be deeply familiar with the standard.  As such, it
is a problem that the standard is not freely or even widely available.

Let's get back to what you originally proposed.  You want to be able
to write 1000000 as 1_000_000 for legibility.  This would be easy to
implement and I agree that it would be an improvement.  What you need
to do is decide exactly what the extended syntax is supposed to be.
For instance, are you allowed to write any of the following?

	16777216_UL
	16777216U_L
	0._1234
	0x_1234
	12.34_e+56
	12.34e_+56

All but the last are legitimate "preprocessing numbers".  I can tell
you right now that I'll be a lot more receptive to an extension that
doesn't change the definition of a preprocessing number.

You should investigate the rules for numeric syntax in languages
which already have this notation, such as Ada and Perl.

Once you've done an exhaustive analysis and decided what your syntax
is going to be, you should submit a patch which implements and
documents the new extension.  We will then consider it.

Oh, and file your copyright assignment paperwork now; the turnaround
time can be several months and we can't take any nontrivial patch of
yours until it's come back.

> I'm looking for some webspace for feature proposals, performance
> issues and warning issues.
> 
> And someone who translates my "pseudo English" into "real English".

Please feel free to submit patches to our website.  (You need not file
copyright paperwork to do this.)  You can check it out of CVS with

cvs -d :pserver:anoncvs@gcc.gnu.org:/cvs/gcc co wwwdocs

Read through the existing htdocs/projects directory first, please.

There are plenty of native English speakers on this list who will be
happy to help you with phrasing and so on.

zw

Re: Proposal

[Neil Booth]

Zack Weinberg wrote:-

> Let's get back to what you originally proposed.  You want to be able
> to write 1000000 as 1_000_000 for legibility.  This would be easy to
> implement and I agree that it would be an improvement.  What you need
> to do is decide exactly what the extended syntax is supposed to be.
> For instance, are you allowed to write any of the following?
> 
> 	16777216_UL  [1]
> 	16777216U_L  [2]
> 	0._1234      [3]
> 	0x_1234      [4]
> 	12.34_e+56   [5]
> 	12.34e_+56   [6]
> 
> All but the last are legitimate "preprocessing numbers".  I can tell
> you right now that I'll be a lot more receptive to an extension that
> doesn't change the definition of a preprocessing number.

I don't think we want to accept anything that changes the pp-number
definition; I consider it set it stone.

I've labelled your examples above.  [6] is not a pp-number, so I'd
rule it out from the start.

For the rest, I see two reasonable things to say:

1) A pp-number with '_' in it is interpreted as if all '_' were stripped
   out initially.

2) We allow _ only in the integer part of decimals / hex / floats, but
   anywhere and anyhow in those parts.  Not valid in suffixes.  Interpreted
   as if the '_' were stripped out.  This would invalidate [2], [3] and [5].

Anything more complex is probably not worth it.  1) is appealling
merely because it is simple and unambiguous.

Neil.

Re: Proposal

[Tim Hollebeek]

> Anything more complex is probably not worth it.

Long decimals benefit just as much as large integers
do. "3.141_592_653_529" should be legal too.

Re: Proposal

[Richard Earnshaw]

> 
> > Anything more complex is probably not worth it.
> 
> Long decimals benefit just as much as large integers
> do. "3.141_592_653_529" should be legal too.

As should (IMO) 0xffff_0000_ffff_ffffUL

Which means it has to be a little more general than "decimal digit"

R.

Re: Proposal

[Joe Buck]

Frank Klemm writes:

> Most programmers don't know the standard and are not interested in knowing
> the standard, because their (present) job is to solve a problem for one or
> two different systems, not for every theoretically possible system,
> and the standard supports nearly every stuff which has more than 4 pins ;-)

In my case, I have access to the standard, but its relevance to my
day-to-day work is limited, since I have to get my code past six different
implementations that all get the standard wrong.  So "is this correct ISO
C or C++" may be interesting, but "do all my targeted compilers get this
right, if not, how do I avoid a sea of #ifdefs" is more interesting.

> Programming portable, especially with C, takes much more time than
> programming for a special system, and the programmers don't have this time.

The standard does not tell one how to go about "programming portable",
because compiler vendors do not correctly implement the standard.  It
certainly helps, true, because compiler vendors have at least read the
thing and made some effort to comply, often with a long list of caveats
(especially in the case of C++).

The parts of the standard that most experienced programmers are not
familiar with tend also to be the parts of the standard that are
implemented incorrectly.

Re: Proposal

[Robert Lipe]

Zack Weinberg wrote:

> I'd also point out that very few people have access to the standard;
> yes, ANSI sells copies for not-totally-outrageous sums, but many don't
> know that and the cost may still be too high.

ANSI sells online copies for $18 USD.  It's a 1.4Mb PDF.   Looking again,
I see it at:

 http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI%2FISO%2FIEC+9899%2D1999

(Do we have any hangups about referencing "non-free" documents in 'readings'?)


That said, I'm on the side that's very much NOT in favor of introducing 
more incompatible language extensions.

RJL

Re: Proposal

[Russ Allbery]

Robert Lipe <robertlipe@usa.net> writes:

> ANSI sells online copies for $18 USD.  It's a 1.4Mb PDF.  Looking again,
> I see it at:

>  http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI%2FISO%2FIEC+9899%2D1999

> (Do we have any hangups about referencing "non-free" documents in
> 'readings'?)

The hangup in this case is likely to be the click-through license on that
PDF file, which has some highly obnoxious clauses in it even above and
beyond not allowing redistribution.

-- 
Russ Allbery (rra@stanford.edu)             < http://www.eyrie.org/~eagle/ >

Re: Proposal

[Kai Henningsen]

rra@stanford.edu (Russ Allbery)  wrote on 18.09.01 in < yly9ncoxsp.fsf@windlord.stanford.edu >:

> Robert Lipe <robertlipe@usa.net> writes:
>
> > ANSI sells online copies for $18 USD.  It's a 1.4Mb PDF.  Looking again,
> > I see it at:
>
> >  http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI%2FISO%2FIEC+98
> >  99%2D1999
>
> > (Do we have any hangups about referencing "non-free" documents in
> > 'readings'?)
>
> The hangup in this case is likely to be the click-through license on that
> PDF file, which has some highly obnoxious clauses in it even above and
> beyond not allowing redistribution.

From the last discussion about said license, it essentially said "we won't  
be sued for that standard, no matter what you use it for", in lawyerese. I  
thought that was entirely reasonable.

MfG Kai

Re: Proposal

[Russ Allbery]

Kai Henningsen <kaih@khms.westfalen.de> writes:
> rra@stanford.edu (Russ Allbery) wrote:

>> The hangup in this case is likely to be the click-through license on
>> that PDF file, which has some highly obnoxious clauses in it even above
>> and beyond not allowing redistribution.

> From the last discussion about said license, it essentially said "we
> won't be sued for that standard, no matter what you use it for", in
> lawyerese. I thought that was entirely reasonable.

It also says that if someone sues them, you pay their legal fees.  That's
the bit that's rather iffier.

I should clarify that I didn't consider it a sufficient drawback to avoid
buying it personally, but I can understand how other people would be leery
of it.

-- 
Russ Allbery (rra@stanford.edu)             < http://www.eyrie.org/~eagle/ >

Re: Proposal

[Frank Klemm]

On Mon, Sep 17, 2001 at 11:59:28PM +0100, Neil Booth wrote:
> 
> > It is not allowed to compose numbers with '_' inside of macros.
> > 
> >   #define MILLION	_MERGE5 ( 1, _, 000, _, 000 )
> > 
> > This allows easily to write a filter to generate C89 or C99 files.
> 
> I don't understand quite what you're saying here.  If you're saying
> dissallow concatenation with ## then I would strenuously object, since
> 
> 1) disallowing it seems gratuitous,
> 2) it's specifically allowed by the standard, and
> 3) it would be introducing yet more special cases to the preprocessor,
>    which already has too many of those for my liking.
> 
For instance you have a program which uses _ in numbers. 
But not all compilers will will support this in the beginning.

It should be possible to write a program which removes these _ inside of
numbers to allow to compile such source files with other compilers.

Without this rule it is impossible to write such a program without
preprocessing the source file. And preprocessed files are no source files
anymore.

To prevent this it is forbidden to use this feature in conjunction with
token concatenation. At least as long as this is not an ISO standard.

For instance try to convert 

   #define MILLION	MY_MERGE_5 ( 1, _, 000, _, 000 )

to the old representation. Note that MY_MERGE_5 is a self defined macro.

-- 
Frank Klemm

Re: Proposal

[Neil Booth]

Frank Klemm wrote:-

> For instance you have a program which uses _ in numbers. 
> But not all compilers will will support this in the beginning.

Sure.

> It should be possible to write a program which removes these _ inside of
> numbers to allow to compile such source files with other compilers.

If the _'s aren't already in your source code, I don't see much point
putting them there with macros.  Wasn't the whole idea legibility?

> Without this rule it is impossible to write such a program without
> preprocessing the source file. And preprocessed files are no source files
> anymore.

Well, you might be able to filter it through sed or something, with a
little difficulty.

> To prevent this it is forbidden to use this feature in conjunction with
> token concatenation. At least as long as this is not an ISO standard.
> 
> For instance try to convert 
> 
>    #define MILLION	MY_MERGE_5 ( 1, _, 000, _, 000 )
> 
> to the old representation. Note that MY_MERGE_5 is a self defined macro.

I don't know what you mean by a self-defined macro.  I don't
understand why you're using macros (see comment above).  I'm not even
sure what the definition of MY_MERGE_5 is, though I might guess.

Anyway, if you insist on macros, you could get what you want through
an extra indirection, and an extra macro

#if COMPILER_UNDERSTANDS_EXTENDED_NUMBERS
#define UNDERSCORE _
#else
#define UNDERSCORE
#endif

#define MY_MERGE_5_INDIRECT (a, b, c, d, e) MY_MERGE_5 (a, b, c, d, e)
#define MILLION	MY_MERGE_5_INDIRECT (1, UNDERSCORE, 000, UNDERSCORE, 000)

But I really can't see the point here.

Neil.

Re: Proposal

[Kevin Handy]

Frank Klemm wrote:
> 
> On Mon, Sep 17, 2001 at 11:59:28PM +0100, Neil Booth wrote:
> >
> > > It is not allowed to compose numbers with '_' inside of macros.
> > >
> > >   #define MILLION   _MERGE5 ( 1, _, 000, _, 000 )
> > >

[snip]

> For instance you have a program which uses _ in numbers.
> But not all compilers will will support this in the beginning.
> 
> It should be possible to write a program which removes these _ inside of
> numbers to allow to compile such source files with other compilers.
> 
> Without this rule it is impossible to write such a program without
> preprocessing the source file. And preprocessed files are no source files
> anymore.
> 
> To prevent this it is forbidden to use this feature in conjunction with
> token concatenation. At least as long as this is not an ISO standard.
> 
> For instance try to convert
> 
>    #define MILLION      MY_MERGE_5 ( 1, _, 000, _, 000 )

If you are using the underscore to make numbers more readable, then
using a macro like this doesn't seem to me to be a step in the right
direction. This looks (to me) to be harder to understand than a
simple '1000000' would be.

Another option for this that I'd prefer would be to write

#define MY_MERGE_3(a,b,c) (a*1000000 + b*1000 + c)
#define MILLION   MY_MERGE_3(1,000,000)

which doesn't need the extension, and you get to use comma's as the
separator which is what people normally expect. This example is
somewhat stupid, in that the million (1000000) constant is also
the MY_MERGE_3 definition, but you still get the idea.

> to the old representation. Note that MY_MERGE_5 is a self defined macro.

Someone could write a "preprocessor" in C (which you should have a
compiler for since you are trying to compile C code) that would
filter out the underscores in numbers. Then you could distribute
it along with your code for those running the wrong C compiler.
Not the greatest solution, but I'd think it would be better to
either use the extension or not.

Re: Proposal

[Neil Booth]

Kevin Handy wrote:-

> Another option for this that I'd prefer would be to write
> 
> #define MY_MERGE_3(a,b,c) (a*1000000 + b*1000 + c)
> #define MILLION   MY_MERGE_3(1,000,000)
> 
> which doesn't need the extension, and you get to use comma's as the
> separator which is what people normally expect. This example is
> somewhat stupid, in that the million (1000000) constant is also
> the MY_MERGE_3 definition, but you still get the idea.

Careful, those are octal numbers 8-)

Neil.

Re: Proposal

[Toon Moene]

Neil Booth wrote:

> Kevin Handy wrote:-

> > Another option for this that I'd prefer would be to write
> >
> > #define MY_MERGE_3(a,b,c) (a*1000000 + b*1000 + c)
> > #define MILLION   MY_MERGE_3(1,000,000)

> Careful, those are octal numbers 8-)

How about using Fortran ?

      PRINT*, 1 000 000
      END

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: Proposal

[Alexandre Oliva]

On Sep 17, 2001, Frank Klemm <pfk@fuchs.offl.uni-jena.de> wrote:

> For instance try to convert 

>    #define MILLION	MY_MERGE_5 ( 1, _, 000, _, 000 )

If you're going down this road, I'd rather just do

#define MILLION MERGE3(1, 000, 000)

where

#define MERGE3(a,b,c) a##b##c

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Proposal

[Frank Klemm]

On Thu, Sep 27, 2001 at 05:17:40AM -0300, Alexandre Oliva wrote:
> On Sep 17, 2001, Frank Klemm <pfk@fuchs.offl.uni-jena.de> wrote:
> 
> > For instance try to convert 
> 
> >    #define MILLION	MY_MERGE_5 ( 1, _, 000, _, 000 )
> 
> If you're going down this road, I'd rather just do
> 
> #define MILLION MERGE3(1, 000, 000)
> 
> where
> 
> #define MERGE3(a,b,c) a##b##c
> 
Everyone misinterprets this example.

This is not an example to write 'grouped' numbers.

It is an example what must be forbidden to be able to write a filter program
which removes '_' from numbers.

'_' should be allowed in numbers. It is allowed between the digits of
numbers in a C/C++ source _before_ preprocessing. It is not allowed between
digits which are 'created' during the preprocessor phase.

It is nearly impossible to write a filter which recognizes such '_'
and removes it. This is the reason for this rule. If gcc introduces a '_' in
numbers, such a filter is a MUST.


Exercise: 
  Write a program which translates the following C_99 program to C99:

------------------------------------------------------------------------
#include <stdio.h>

#define MY_MERGE_5(a,b,c,d,e)  a##b##c##d##e  
#define MILLION                MY_MERGE_5 ( 1, _, 000, _, 000 )
#define BILLION	               MY_MERGE_5 ( MILLION, _, 000, _, 000 )	// UK notation
#define VAR		       MY_MERGE_5 ( a, _, b, _, c )
#define VAR2		       MY_MERGE_5 ( a, b, c, d, e )

int  
main ( void ) 
{
    int        abc   = MILLION;
    int        VAR   = MILLION;
    long long  x     = BILLION;
    int        VAR2  = MILLION;

    printf ("%d %d %lld %d %d\n", abc, VAR, x, VAR2, abcde );
    printf ("1000000 1000000 1000000000000 1000000 1000000\n" );
    return 0;
}
-----------------------------------------------------------------------

-- 
Frank Klemm

Re: Proposal

[Zack Weinberg]

On Thu, Sep 27, 2001 at 04:07:55PM +0200, Frank Klemm wrote:
> On Thu, Sep 27, 2001 at 05:17:40AM -0300, Alexandre Oliva wrote:
> > On Sep 17, 2001, Frank Klemm <pfk@fuchs.offl.uni-jena.de> wrote:
> > 
> > > For instance try to convert 
> > 
> > >    #define MILLION	MY_MERGE_5 ( 1, _, 000, _, 000 )
> > 
> > If you're going down this road, I'd rather just do
> > 
> > #define MILLION MERGE3(1, 000, 000)
> > 
> > where
> > 
> > #define MERGE3(a,b,c) a##b##c
> > 
> Everyone misinterprets this example.
> 
> This is not an example to write 'grouped' numbers.
> 
> It is an example what must be forbidden to be able to write a filter program
> which removes '_' from numbers.

Nonsense.  Your filter program can simply sit between the preprocessor
and the compiler.

zw

Re: Proposal

[Frank Klemm]

On Thu, Sep 27, 2001 at 04:22:09PM -0700, Zack Weinberg wrote:
> On Thu, Sep 27, 2001 at 04:07:55PM +0200, Frank Klemm wrote:
> > On Thu, Sep 27, 2001 at 05:17:40AM -0300, Alexandre Oliva wrote:
> > > On Sep 17, 2001, Frank Klemm <pfk@fuchs.offl.uni-jena.de> wrote:
> > > 
> > > > For instance try to convert 
> > > 
> > > >    #define MILLION	MY_MERGE_5 ( 1, _, 000, _, 000 )
> > > 
> > > If you're going down this road, I'd rather just do
> > > 
> > > #define MILLION MERGE3(1, 000, 000)
> > > 
> > > where
> > > 
> > > #define MERGE3(a,b,c) a##b##c
> > > 
> > Everyone misinterprets this example.
> > 
> > This is not an example to write 'grouped' numbers.
> > 
> > It is an example what must be forbidden to be able to write a filter program
> > which removes '_' from numbers.
> 
> Nonsense.  Your filter program can simply sit between the preprocessor
> and the compiler.
> 
This do not work. Preprocessed files are not suitable for distribution.

    blafasel-KandR.tar.Z
    blafasel-C89.tar.gz
    blafasel-C99.tar.bz2
    blafasel-C_99.tar.bz2

You write the source in C_99 and you also want to distribute the source as
C99, so you can also compile the source with other binary only compilers.
   
-- 
Frank Klemm

Re: Proposal

[Zack Weinberg]

On Sat, Sep 29, 2001 at 08:08:11PM +0200, Frank Klemm wrote:
> > 
> > Nonsense.  Your filter program can simply sit between the preprocessor
> > and the compiler.
> > 
> This do not work. Preprocessed files are not suitable for distribution.
> 
>     blafasel-KandR.tar.Z
>     blafasel-C89.tar.gz
>     blafasel-C99.tar.bz2
>     blafasel-C_99.tar.bz2
> 
> You write the source in C_99 and you also want to distribute the source as
> C99, so you can also compile the source with other binary only compilers.

You distribute the C_99 version of the code and include the filter
programs which translate it to C99/C89/K+R.  You wire them into your
Makefile according to what your configure script determines are the
features of the compiler being used.

zw

Re: Proposal

[Neil Booth]

Frank Klemm wrote:-

> '_' should be allowed in numbers. It is allowed between the digits of
> numbers in a C/C++ source _before_ preprocessing. It is not allowed between
> digits which are 'created' during the preprocessor phase.

Why are you so keen to disallow it in created tokens?  If a patch to
implement '_' in numbers were submitted, I would require that a
preprocessing number be a pp number no matter how it is created; I'm
pretty sure Zack would agree with me.

> #define MY_MERGE_5(a,b,c,d,e)  a##b##c##d##e  
> #define MILLION                MY_MERGE_5 ( 1, _, 000, _, 000 )
> #define BILLION	               MY_MERGE_5 ( MILLION, _, 000, _, 000 )	// UK notation

BILLION won't expand to what you think.  As for UK notation, I'm
British and I can't think of the last time I've seen a billion have 12
zeroes.  In fact, I think the only time it occurs is when people are
comparing the claimed British and American forms :-)

Neil.

Re: Proposal

[Frank Klemm]

On Fri, Sep 28, 2001 at 12:36:13AM +0100, Neil Booth wrote:
> Frank Klemm wrote:-
> 
> > '_' should be allowed in numbers. It is allowed between the digits of
> > numbers in a C/C++ source _before_ preprocessing. It is not allowed between
> > digits which are 'created' during the preprocessor phase.
> 
> Why are you so keen to disallow it in created tokens? 
>
Write a filter which converts a C_99 source file to C99.
The first with this restriction, the second without.

It must be pssoible to translate such source file with "old" compilers.


> If a patch to implement '_' in numbers were submitted, I would require
> that a preprocessing number be a pp number no matter how it is created;
> I'm pretty sure Zack would agree with me.
> 
> > #define MY_MERGE_5(a,b,c,d,e)  a##b##c##d##e  
> > #define MILLION                MY_MERGE_5 ( 1, _, 000, _, 000 )
> > #define BILLION	               MY_MERGE_5 ( MILLION, _, 000, _, 000 )	// UK notation
> 
> BILLION won't expand to what you think.  As for UK notation, I'm
> British and I can't think of the last time I've seen a billion have 12
> zeroes.  In fact, I think the only time it occurs is when people are
> comparing the claimed British and American forms :-)
> 
A billion has no zeros: 1.e+12

-- 
Frank Klemm

Re: Proposal

[Daniel Jacobowitz]

On Sat, Sep 29, 2001 at 07:55:53PM +0200, Frank Klemm wrote:
> On Fri, Sep 28, 2001 at 12:36:13AM +0100, Neil Booth wrote:
> > Frank Klemm wrote:-
> > 
> > > '_' should be allowed in numbers. It is allowed between the digits of
> > > numbers in a C/C++ source _before_ preprocessing. It is not allowed between
> > > digits which are 'created' during the preprocessor phase.
> > 
> > Why are you so keen to disallow it in created tokens? 
> >
> Write a filter which converts a C_99 source file to C99.
> The first with this restriction, the second without.
> 
> It must be pssoible to translate such source file with "old" compilers.

If you're that interested in portability, simply do not use this
construct!  That's the way the game is played.  Your restriction buys
nothing except complexity.

> > If a patch to implement '_' in numbers were submitted, I would require
> > that a preprocessing number be a pp number no matter how it is created;
> > I'm pretty sure Zack would agree with me.
> > 
> > > #define MY_MERGE_5(a,b,c,d,e)  a##b##c##d##e  
> > > #define MILLION                MY_MERGE_5 ( 1, _, 000, _, 000 )
> > > #define BILLION	               MY_MERGE_5 ( MILLION, _, 000, _, 000 )	// UK notation
> > 
> > BILLION won't expand to what you think.  As for UK notation, I'm
> > British and I can't think of the last time I've seen a billion have 12
> > zeroes.  In fact, I think the only time it occurs is when people are
> > comparing the claimed British and American forms :-)
> > 
> A billion has no zeros: 1.e+12

I think that what Neil meant is:
% units billion
        Definition: 1e9 = 1e+09


-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

OT: Re: Proposal

[Michael Matz]

Hi,

On Sat, 29 Sep 2001, Daniel Jacobowitz wrote:

> > > BILLION won't expand to what you think.  As for UK notation, I'm
> > > British and I can't think of the last time I've seen a billion have 12
> > > zeroes.  In fact, I think the only time it occurs is when people are
> > > comparing the claimed British and American forms :-)
> > >
> > A billion has no zeros: 1.e+12
>
> I think that what Neil meant is:
> % units billion
>         Definition: 1e9 = 1e+09

May be for your country.  E.g. germany has billion==1e12 (we have mi-,
bi-, tri-, quadri- and quinti- as first parts and -llion, and -lliard(e)
as second parts alternating.  I.e million==1e6, milliard(e)==1e9,
billion==1e12, billiarde=1e15 ... quintilliarde==1e33) for those, who are
interested ;-)

Given that a million is 1e6 in both countries, and a _bi_llion is somehow
two times a m(ono)illion, and 1e9 is neither the double of 1e6 nor has
twice as much zeros, whereas 1e12 has, I find our definition more logical.
But then again I may be biased ;)


Ciao,
Michael.

Re: Proposal

[Fergus Henderson]

On 27-Sep-2001, Frank Klemm <pfk@fuchs.offl.uni-jena.de> wrote:
> '_' should be allowed in numbers. It is allowed between the digits of
> numbers in a C/C++ source _before_ preprocessing. It is not allowed between
> digits which are 'created' during the preprocessor phase.
> 
> It is nearly impossible to write a filter which recognizes such '_'
> and removes it. This is the reason for this rule. If gcc introduces a '_' in
> numbers, such a filter is a MUST.

I disagree that such a filter is necessary.
I think a filter which just handled the cases that don't involve
token concatenation would be quite sufficient.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.