Re: GCC 4.0.2 RC1 Available
Mark Mitchell <[EMAIL PROTECTED]> writes: > GCC 4.0.2 RC1 is now available from FTP mirrors of gcc.gnu.org, in the: > > pub/gcc/prerelease-4.0.2-20050913/ > > subdirectory. > > It's important to test the actual tarballs, rather than CVS, to check > for any packaging issues. If you can, download and build the tarballs, > post test results to the gcc-testresults mailing list with and > contrib/test_summary. Looks good for mips-elf. All failures are expected: http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00812.html Richard
Warning C vs C++
Hello,
Consider following snippet:
#include
int main (int argc, char *argv[])
{
char *s1 = argv[0];
char *s2 = strchr (s1, '/');
char r;
(void) argc;
r = s2 ? (s2 - s1) : strlen (s1);
return 0;
}
And the results of compilation:
cvscxx$ gcc-4.0.0 -Wall -Werror -c cvscxx.c && echo Success
Success
cvscxx$ gcc-4.0.0 -Wall -Werror -W -c cvscxx.c && echo Success
cc1: warnings being treated as errors
cvscxx.c: In function 'main':
cvscxx.c:11: warning: signed and unsigned type in conditional expression
cvscxx$ g++-4.0.0 -Wall -Werror -W -c cvscxx.c && echo Success
Success
Questions:
a. Why it does not err on just -Wall?
b. Why is error message with -W what it is? instead of something like
what microsoft's compiler produces:
cl /Wall /c cvscxx.c
cvscxx.c(11) : warning C4244: '=' : conversion from 'size_t' to 'unsigned
char', possible loss of data
c. Why when compiled with C++ compiler there is no warning at all even with
-W (or even -Wextra)?
d. What is actual type of the ?: expression? ptrdiff_t? size_t?
Re: Warning C vs C++
Vassili Karpov <[EMAIL PROTECTED]> writes:
Since this e-mail is not about gcc development, it should have been
sent to [EMAIL PROTECTED], not to [EMAIL PROTECTED] Thanks.
> #include
>
> int main (int argc, char *argv[])
> {
> char *s1 = argv[0];
> char *s2 = strchr (s1, '/');
> char r;
>
> (void) argc;
>
> r = s2 ? (s2 - s1) : strlen (s1);
> return 0;
> }
> a. Why it does not err on just -Wall?
The warning is controlled by -Wsign-compare, which is turned on by
-Wextra (also known as -W) but not by -Wall. It's not turned on by
-Wall because it is not normally a problem.
> b. Why is error message with -W what it is? instead of something like
>what microsoft's compiler produces:
>
>cl /Wall /c cvscxx.c
>cvscxx.c(11) : warning C4244: '=' : conversion from 'size_t' to 'unsigned
>
> char', possible loss of data
As far as I can tell, gcc does not warn about narrowing assignments.
I don't think people would object to adding such a warning, though
probably not under -Wall. If you want to make an enhancement request,
please file it at http://gcc.gnu.org/bugzilla/. Thanks.
> c. Why when compiled with C++ compiler there is no warning at all even with
>-W (or even -Wextra)?
The C and C++ frontends are different. The C++ frontend doesn't
happen to have this particular warning. In othe words, there is no
good reason. Again I don't think people would object to adding the
warning to C++.
> d. What is actual type of the ?: expression? ptrdiff_t? size_t?
The actual type is size_t, because in C, in an expression which uses
both a signed type and an unsigned type of the same size, the signed
type is converted to the unsigned type.
Ian
pointer checking run time code
Hi all, I am trying to insert code which before pointer dereferences would check if the pointer dereference is valid. As this might mean a lot of overhead, I was wondering where would be the best place to insert it so that the overhead can be opitimized away. Especially, I was wondering if any optimization would hoist the check outside loops. Can I inline it and hope some code will get hoisted ? Or do I have to do it explicitly ? The check is likely to be a function call that checks the pointer values against some bounds. Ideas, other pointers would be great Shrey
Re: pointer checking run time code
shreyas krishnan wrote: Ideas, other pointers would be great Note that of course this kind of check is standard in Ada and hence in GNAT, so you can get an idea from GNAT generated code how well the backend can eliminate such checks (answer: getting better with gcc 4).
Re: Warning C vs C++
On Saturday 17 September 2005 15:16, Ian Lance Taylor wrote: > > The warning is controlled by -Wsign-compare, which is turned on by > -Wextra (also known as -W) but not by -Wall. It's not turned on by > -Wall because it is not normally a problem. That's strange, all users I know expected it to turn ALL warnings, hence name. If it doesn't do it, perhaps it should. That's basic usability faux pax, excuse me. -- Vercetti
Re: Warning C vs C++
On Sat, 17 Sep 2005, Ian Lance Taylor wrote: > As far as I can tell, gcc does not warn about narrowing assignments. > I don't think people would object to adding such a warning, though > probably not under -Wall. If you want to make an enhancement request, > please file it at http://gcc.gnu.org/bugzilla/. Thanks. Bug 9072 is the bug tracking the need for a better -Wconversion (to warn for any implicit conversion which may change a value). We don't need a new bug for this. (Bug 6614 tracks other specific problems with the current -Wconversion.) -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: Warning C vs C++
Tommy Vercetti <[EMAIL PROTECTED]> writes: | On Saturday 17 September 2005 15:16, Ian Lance Taylor wrote: | | > | > The warning is controlled by -Wsign-compare, which is turned on by | > -Wextra (also known as -W) but not by -Wall. It's not turned on by | > -Wall because it is not normally a problem. | That's strange, all users I know expected it to turn ALL warnings, then all you users you know don't read the doc. That is rather disappointing, but not uncommon. -- Gaby
Re: [PATCH] fix warnings in treelang/parse.y
On Saturday 17 September 2005 01:31, Gabriel Dos Reis wrote:
> See the documentation for pp_base_format() in $GCC/gcc/pretty-print.c
Thanks
> The changes are basically OK. As a bonus, you might to take the
> opportunity to remove the trailing periods and decapitalize the first
> words.
attached :)
bootstrapped and tested (make check-treelang) in i686
Rafael
2005-09-13 Rafael Ávila de Espíndola <[EMAIL PROTECTED]>
* parse.y : Fixed two compile warnings in "error" and
"warning" invocations
Removed trailing periods in messages
Decapitalized the first word of each
message
Index: gcc/treelang/parse.y
===
RCS file: /cvsroot/gcc/gcc/gcc/treelang/parse.y,v
retrieving revision 1.27
diff -c -3 -p -r1.27 parse.y
*** gcc/treelang/parse.y 25 Jun 2005 00:59:41 - 1.27
--- gcc/treelang/parse.y 17 Sep 2005 13:07:45 -
*** storage typename NAME init_opt SEMICOLON
*** 201,207
gcc_assert (((struct prod_token_parm_item*)VAR_INIT (prod))->tp.pro.code);
if (STORAGE_CLASS (prod) == EXTERNAL_REFERENCE_STORAGE)
{
! error("%HExternal reference variable %q.*s has an initial value.",
&tok->tp.tok.location, tok->tp.tok.length, tok->tp.tok.chars);
YYERROR;
VAR_INIT (prod) = NULL;
--- 201,207
gcc_assert (((struct prod_token_parm_item*)VAR_INIT (prod))->tp.pro.code);
if (STORAGE_CLASS (prod) == EXTERNAL_REFERENCE_STORAGE)
{
! error("%Hexternal reference variable %q.*s has an initial value",
&tok->tp.tok.location, tok->tp.tok.length, tok->tp.tok.chars);
YYERROR;
VAR_INIT (prod) = NULL;
*** storage typename NAME LEFT_PARENTHESIS p
*** 278,284
break;
case AUTOMATIC_STORAGE:
! error ("%HFunction %q.*s cannot be automatic.",
&tok->tp.tok.location, tok->tp.tok.length, tok->tp.tok.chars);
YYERROR;
break;
--- 278,284
break;
case AUTOMATIC_STORAGE:
! error ("%Hfunction %q.*s cannot be automatic",
&tok->tp.tok.location, tok->tp.tok.length, tok->tp.tok.chars);
YYERROR;
break;
*** NAME LEFT_BRACE {
*** 351,357
current_function = proto = lookup_tree_name (&search_prod);
if (!proto)
{
! error ("%HNo prototype found for %q.*s", &tok->tp.tok.location,
tok->tp.tok.length, tok->tp.tok.chars);
YYERROR;
}
--- 351,357
current_function = proto = lookup_tree_name (&search_prod);
if (!proto)
{
! error ("%Hno prototype found for %q.*s", &tok->tp.tok.location,
tok->tp.tok.length, tok->tp.tok.chars);
YYERROR;
}
*** tl_RETURN expression_opt {
*** 527,540
tree_code_generate_return (type_prod->tp.pro.code, NULL);
else
{
! warning (0, "%HRedundant expression in return.",
! &ret_tok->tp.tok.location, ret_tok->tp.tok.length,
! ret_tok->tp.tok.chars);
tree_code_generate_return (type_prod->tp.pro.code, NULL);
}
else
if (exp == NULL)
! error ("%HExpression missing in return.", &ret_tok->tp.tok.location);
else
{
/* Check same type. */
--- 527,539
tree_code_generate_return (type_prod->tp.pro.code, NULL);
else
{
! warning (0, "%Hredundant expression in return",
! &ret_tok->tp.tok.location);
tree_code_generate_return (type_prod->tp.pro.code, NULL);
}
else
if (exp == NULL)
! error ("%Hexpression missing in return", &ret_tok->tp.tok.location);
else
{
/* Check same type. */
*** NAME LEFT_PARENTHESIS expressions_with_c
*** 637,643
proto = lookup_tree_name (&search_prod);
if (!proto)
{
! error ("%HFunction prototype not found for %q.*%s.",
&tok->tp.tok.location, tok->tp.tok.length, tok->tp.tok.chars);
YYERROR;
}
--- 636,642
proto = lookup_tree_name (&search_prod);
if (!proto)
{
! error ("%Hfunction prototype not found for %q.*s",
&tok->tp.tok.location, tok->tp.tok.length, tok->tp.tok.chars);
YYERROR;
}
*** NAME LEFT_PARENTHESIS expressions_with_c
*** 653,659
if (exp_count != exp_proto_count)
{
! error ("%HExpression count mismatch %q.*s with prototype.",
&tok->tp.tok.location, tok->tp.tok.length, tok->tp.tok.chars);
YYERROR;
}
--- 652,658
if (exp_count != exp_proto_count)
{
! error ("%Hexpression count mismatch %q.*s with prototype",
&tok->tp.tok.location, tok->tp.tok.length, tok->tp.tok.chars);
YYERROR;
}
*** NAME {
*** 720,726
symbol_table_entry = lookup_tree_name (&search_prod);
if (!symbol_table_entry)
{
! error ("%HVariable %q.*s not defined.",
&
Re: GCC 4.0.2 RC1 Available
Looks good on powerp-ibm-aix5.2.0.0. All expected failures. http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00806.html David
Re: Warning C vs C++
On Saturday 17 September 2005 16:23, Gabriel Dos Reis wrote: > then all you users you know don't read the doc. That is rather > disappointing, but not uncommon. It's not that everyone reads manual, you should know. I personally only read it, when I am missing some piece of information. Do a survey and see how many ppl would expect the word all to not include everything. And you'll see yourself. -- Vercetti
Re: Warning C vs C++
Tommy Vercetti <[EMAIL PROTECTED]> writes: | On Saturday 17 September 2005 16:23, Gabriel Dos Reis wrote: | > then all you users you know don't read the doc. That is rather | > disappointing, but not uncommon. | It's not that everyone reads manual, you should know. You may probably have missed the second part of the last sentence. | I personally only read it, when I am missing some piece of | information. then here is news for you: you're missing the meaning of -Wall. | Do a survey and see how many ppl would expect the word | all to not include everything. And you'll see yourself. I would also encourage you to conduct a survey of bug frequency in codes of people who write programs using functions by *guessing* their meanings instead of reading the docs. I suspect you have much bigger issue to fix than complaining that your guess does not match the reality you decided not to check. -- Gaby
Re: [PATCH] fix warnings in treelang/parse.y
Rafael Ávila de Espíndola <[EMAIL PROTECTED]> writes: | On Saturday 17 September 2005 01:31, Gabriel Dos Reis wrote: | > See the documentation for pp_base_format() in $GCC/gcc/pretty-print.c | Thanks | > The changes are basically OK. As a bonus, you might to take the | > opportunity to remove the trailing periods and decapitalize the first | > words. | attached :) | | bootstrapped and tested (make check-treelang) in i686 Patch OK. -- Gaby
Re: Warning C vs C++
Tommy Vercetti wrote: On Saturday 17 September 2005 15:16, Ian Lance Taylor wrote: The warning is controlled by -Wsign-compare, which is turned on by -Wextra (also known as -W) but not by -Wall. It's not turned on by -Wall because it is not normally a problem. That's strange, all users I know expected it to turn ALL warnings, hence name. If it doesn't do it, perhaps it should. That's basic usability faux pax, excuse me. That's a real misunderstanding. There are many warnings that are very specialized, and if -Wall really turned on all warnings, it would be essentially useless. The idea behind -Wall is that it represents a comprehensive set of warnings that most/many programmers can live with. To turn on all warnings would be the usability faux pas.
Re: Warning C vs C++
Tommy Vercetti wrote: On Saturday 17 September 2005 16:23, Gabriel Dos Reis wrote: then all you users you know don't read the doc. That is rather disappointing, but not uncommon. It's not that everyone reads manual, you should know. I personally only read it, when I am missing some piece of information. Do a survey and see how many ppl would expect the word all to not include everything. And you'll see yourself. Any option names are always abbreviations of the full intent, and if you try to infer features from names alone, you will indeed be lead astray, the all in -Wall is short for "all generally useful warnings".
Re: Warning C vs C++
On Saturday 17 September 2005 17:18, Gabriel Dos Reis wrote: > I would also encourage you to conduct a survey of bug frequency in > codes of people who write programs using functions by *guessing* their > meanings instead of reading the docs. > > I suspect you have much bigger issue to fix than complaining that your > guess does not match the reality you decided not to check. I guess that instead of being not very friendly, you should read my first email first and analyze it bit by bit. Also analyze meaning of the word all. That's all I got to say. ps. please don't CC me, I am on the list. -- Vercetti
Re: Warning C vs C++
Tommy Vercetti wrote: On Saturday 17 September 2005 16:23, Gabriel Dos Reis wrote: then all you users you know don't read the doc. That is rather disappointing, but not uncommon. It's not that everyone reads manual, you should know. I personally only read it, when I am missing some piece of information The trouble is that you don't know when (as in this case) you are missing some piece of information. In particular, when using a compiler, you really want to read through the documentation of options, otherwise, not only will you not know the full story on the options you do know about (as in this case), but more importantly, there is a lot of very important functionality represented by the many switches accepted by gcc that you will simply not know about.
Re: Warning C vs C++
On Saturday 17 September 2005 17:45, you wrote: > That's a real misunderstanding. There are many warnings that are very > specialized, and if -Wall really turned on all warnings, it would be > essentially useless. The idea behind -Wall is that it represents a > comprehensive set of warnings that most/many programmers can live > with. To turn on all warnings would be the usability faux pas. Ok, sure. This option is also used by many developers to see all possible problems in their code. And btw, signed/unsigned isn't a minor problem. Majority of code giving such warning is exploitable (in the black-hackish terms). I am developer myself, but just using gcc, hence my user's opinion. Thank you. -- Vercetti
Re: Warning C vs C++
Tommy Vercetti wrote: On Saturday 17 September 2005 17:45, you wrote: That's a real misunderstanding. There are many warnings that are very specialized, and if -Wall really turned on all warnings, it would be essentially useless. The idea behind -Wall is that it represents a comprehensive set of warnings that most/many programmers can live with. To turn on all warnings would be the usability faux pas. Ok, sure. This option is also used by many developers to see all possible problems in their code. And btw, signed/unsigned isn't a minor problem. Majority of code giving such warning is exploitable (in the black-hackish terms). I am developer myself, but just using gcc, hence my user's opinion. But since you don't read the documentation, you really don't know what warnings are available. If -Wall turned on all warnings, nearly all users would find far too many false positives. Sure everyone wants to see "all possible problems in their code", but warnings that generate too many false positives obscure the very problems you are looking for. It is fine to argue for a specific warning being included in -Wall, though before you do this, you should check for discussions as to why it was not included, and run some tests over large bodies of code to get a feel for the issue of false positives. However, arguing that a warning should be included because TV has looked up the definition of "all" in a dictionary but has not read the gcc documentation is unlikely to be persuasive. Regarding cc,s it is in practice impractical to expect people to go to the trouble of removing you from the cc list. Instead set up your mailer to delete duplicate messages, or, if you don't know how to do that, get some help in doing so.
Re: Warning C vs C++
Tommy Vercetti <[EMAIL PROTECTED]> writes: | On Saturday 17 September 2005 17:45, you wrote: | > That's a real misunderstanding. There are many warnings that are very | > specialized, and if -Wall really turned on all warnings, it would be | > essentially useless. The idea behind -Wall is that it represents a | > comprehensive set of warnings that most/many programmers can live | > with. To turn on all warnings would be the usability faux pas. | Ok, And that is explained in the doc. -- Gaby
Re: Warning C vs C++
Tommy Vercetti <[EMAIL PROTECTED]> writes: | On Saturday 17 September 2005 17:18, Gabriel Dos Reis wrote: | > I would also encourage you to conduct a survey of bug frequency in | > codes of people who write programs using functions by *guessing* their | > meanings instead of reading the docs. | > | > I suspect you have much bigger issue to fix than complaining that your | > guess does not match the reality you decided not to check. | I guess that instead of being not very friendly, I'm being very friendly at pointing you that the proper way to understand what -Wall means is NOT by guessing what a subword could/would mean but by reading the documentation. -- Gaby
Re: pointer checking run time code
On Saturday, September 17, 2005, at 06:41 AM, shreyas krishnan wrote: I am trying to insert code which before pointer dereferences would check if the pointer dereference is valid. Just like mudflap? If so, use those options from the manual.
Re: pointer checking run time code
On Saturday, September 17, 2005, at 10:13 AM, Mike Stump wrote: On Saturday, September 17, 2005, at 06:41 AM, shreyas krishnan wrote: I am trying to insert code which before pointer dereferences would check if the pointer dereference is valid. Just like mudflap? If so, use those options from the manual. And if slightly different, see the mudflap code to get ideas where others found it useful to do things like this...
gcc-4.1-20050917 is now available
Snapshot gcc-4.1-20050917 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050917/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 CVS branch with the following options: -D2005-09-17 17:43 UTC You'll find: gcc-4.1-20050917.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20050917.tar.bz2 C front end and core compiler gcc-ada-4.1-20050917.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20050917.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20050917.tar.bz2 C++ front end and runtime gcc-java-4.1-20050917.tar.bz2 Java front end and runtime gcc-objc-4.1-20050917.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20050917.tar.bz2The GCC testsuite Diffs from 4.1-20050909 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Cost of having an immediate use in the phi argument
It seems the only reason we have PHI_ARG_IMM_USE_NODE (and a struct
ssa_use_operand_d) in a phi node argument (struct phi_arg_d) is *just*
so we can iterate over the uses and hand back use_operand_p.
I'm talking, in particular, about:
struct phi_arg_d GTY(())
{
/* imm_use MUST be the first element in struct because we do some
pointer arithmetic with it. See phi_arg_index_from_use. */
struct ssa_use_operand_d imm_use;
}
It's not actually usfeul as an immediate use, since it doesn't actually
point to an immediate use, and because you can get the argument itself
from PHI_ARG_DEF.
This wastes like 20-30 bytes per phi argument on 64 bit platforms.
If use_operand_p were a structure, or we returned a structure in the
iterator instead of the pointer, we could do without it, because we
could make them up on the fly.
Unless you have a good reason not to do this, i'd rather change the
iterators to return structures (The first thing almost *everyone* does
is call USE_FROM_PTR anyway :P), and remove the imm_use member of phi
arg.
This should save us a noticeable amount of memory.
--Dan
Re: GCC 4.0.2 RC1 Available
Eric Botcazou wrote: >>GCC 4.0.2 RC1 is now available from FTP mirrors of gcc.gnu.org, in the: > > > OK on SPARC/Solaris: Thanks. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: proposed Opengroup action for c99 command (XCU ERN 76)
Joseph S. Myers said: > On Fri, 16 Sep 2005, Zack Weinberg wrote: >> I am with Joe Buck in the opinion that even a 1% performance penalty for >> implementing (A) [or (B)] would be too much -- I suggest this be fixed by >> convincing the C++ committee to allow (C) and not just by phase 1 >> transformations, thus allowing the existing implementation to conform. > > I don't think solutions starting with convincing the committee to fix a > working part of the standard are generally that practical! When the standard is arguably buggy -- if nothing else, it diverges from C and there is no good reason for divergence -- I think working with the committee to improve the standard should always be an option considered. When a simple change to the standard would get you out of having to make a large, complicated change to GCC, and when the standard-mandated semantics are of dubious utility to real users, I think you should try to change the standard before you even start thinking about changing the compiler. I don't disagree strongly with any of your other points, but I do want to mention that foreclosing future improvements in another domain is something that should be considered when making implementation choices, that proper statistical methods *can* detect 1% performance degradations amid the noise, and that -- as pointed out by others -- a pile of 1% degradations adds up to a slow compiler. zw
Re: proposed Opengroup action for c99 command (XCU ERN 76)
"Zack Weinberg" <[EMAIL PROTECTED]> writes: | Joseph S. Myers said: | > On Fri, 16 Sep 2005, Zack Weinberg wrote: | >> I am with Joe Buck in the opinion that even a 1% performance penalty for | >> implementing (A) [or (B)] would be too much -- I suggest this be fixed by | >> convincing the C++ committee to allow (C) and not just by phase 1 | >> transformations, thus allowing the existing implementation to conform. | > | > I don't think solutions starting with convincing the committee to fix a | > working part of the standard are generally that practical! | | When the standard is arguably buggy -- if nothing else, it diverges from C C++98 came before C99, so who diverged from whom? If you do feel so strongly about this, why don't you invest time in sorting this with the committees? -- Gaby
Re: Cross Compiler Unix - Windows
On Tue, 30 Aug 2005, Nix wrote: >> mudflap is an offender as well, see Bugzilla #18244 (libmudflap >> installs include/mf-runtime.h in version-independent path). >> >> Java has libdata/pkgconfig/libgcj.pc and include/ffi.h. >> >> And, like the man pages, the info files do not honor --program-suffix, >> but for regular C, C++, Objective-C and Fortran development neither of >> is a real killer, agreed. > The ffi.h thing really is a bug with consequences: the thing's got > target-dependent contents :/ This is now Bugzilla java/23935 ($PREFIX/include/ffi.h needs to go to a target- and -version-dependent location), in case someone knowledgeable wants to have a look. Gerald
Re: proposed Opengroup action for c99 command (XCU ERN 76)
Gabriel Dos Reis said: > "Zack Weinberg" <[EMAIL PROTECTED]> writes: > | When the standard is arguably buggy -- if nothing else, it diverges from C > > C++98 came before C99, so who diverged from whom? It doesn't matter. The divergence should be resolved in favor of whichever standard has it right, not whichever came first. I happen to think that the C standard, not the C++ standard, has it right, so I argue as I do. > If you do feel so strongly about this, why don't you invest time in > sorting this with the committees? I am not in a position to do that. Others on this list are. zw
Re: proposed Opengroup action for c99 command (XCU ERN 76)
"Zack Weinberg" <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis said: | > "Zack Weinberg" <[EMAIL PROTECTED]> writes: | > | When the standard is arguably buggy -- if nothing else, it diverges from C | > | > C++98 came before C99, so who diverged from whom? | | It doesn't matter. Yet, you're you were construeing it as an argument to support your position. [...] | > If you do feel so strongly about this, why don't you invest time in | > sorting this with the committees? | | I am not in a position to do that. Others on this list are. Please be more explicit. -- Gaby
