pete@borland.com (Pete Becker) writes:

>pete@borland.com (Pete Becker) says:
>>
>>maxtal@Physics.usyd.edu.au (John Max Skaller) says:
>>>
>>>        Borland is free to state certain warnings are diagnostic
>>>error messages and compile the program anyhow. For the compiler
>>>to comply the doco should state this explicitly.
>>
>>Where in the WP does it say this? It is definitely not a requirement
>>in the C standard, nor, as far as I know, a requirement in the current C++
>>working paper.
>
>Whoops, a bit of a dangling modifier their. The "this" in the first sentence
>refers to "the doco should state this explicitly". There is no such
>requirement.

No, John Skaller is correct - the implementation is required to document
what constitutes a "diagnostic".  From the C++ draft working paper:

|   1.3  Definitions                                          [intro.defs]
|
| 1 For the purposes of this International Standard, the definitions given
|   in ISO/IEC 2382 and the following definitions apply.
| [...]
|   --diagnostic message: A message belonging to an implementation-defined
|     subset of the implementation's message output.
| [...]
|   --implementation-defined  behavior:  Behavior,  for  a correct program
|     construct and correct data, that depends on the  implementation  and
|     that  each  implementation  shall  document.   The range of possible
|     behaviors is delineated by the standard.

However, I expect that Borland C++ does provide this documentation.
Turbo C++ 1.0 certainly did.  Appendix A of the documentation for my
old copy of Turbo C++ says the following (referring to section 2.1.1.3
of the ANSI C standard):

| How to identify a diagnostic.
|  When run with the correct combination of options,
|  any message issued by the compiler beginning with the
|  words Fatal, Error, or Warning are diagnostics in the sense
|  that ANSI specifies.

--
Fergus Henderson
fjh@cs.mu.oz.au
http://www.cs.mu.oz.au/~fjh
PGP key fingerprint: 00 D7 A2 27 65 09 B6 AC  8B 3E 0F 01 E7 5D C4 3F

In article <3u97fl$6c7@druid.borland.com>,
Pete Becker <pete@borland.com> wrote:
>In article <3u75b4$e37@metro.ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au (John Max Skaller) says:
>>
>>        Borland is free to state certain warnings are diagnostic
>>error messages and compile the program anyhow. For the compiler
>>to comply the doco should state this explicitly.
>
>Where in the WP does it say this? It is definitely not a requirement
>in the C standard, nor, as far as I know, a requirement in the current C++
>working paper.

 AFAIK It doesn't. IMHO it must. It is useless to say
"a compiler must issue a diagnostic .." if the conformance tester cannot
identify what exactly is a diagnostic. Therefore, since such diagnostics
vary from implementation to implementation, the implementor should
be required to document what constitutes a diagnostic.

 If, in compliance with such a clause, Borland said
that messages staring with "error" were diagnostics and warnings
were not, then failing to issue a diagnostic on binding a
non-const reference to an rvalue would be a conformance violation --
which could be fixed by Borland saying "and message XXXX is also
a diagnostic error message" -- or by changing the text
of the message to say "Error".

 Of course Borland could just say "all messages are diagnostic
error messages". That would be safest from a conformance viewpoint
but might not convince programmers the product was of high quality.
Borland's choice -- as it should be.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <1995Jul7.204804.4882@nlm.nih.gov>,
Bob Kline <bkline@cortex.nlm.nih.gov> wrote:
>: >
>: >BC++ is wrong.
>
>: No, BC++ is not wrong. The information provided is incomplete: BC++
>: generates a warning.
>:  -- Pete
>
>This was made an error back in 1989 when Cfront 2.0 was released.  I
>believe a diagnostic is required here (not just a warning).

 Borland is free to state certain warnings are diagnostic
error messages and compile the program anyhow. For the compiler
to comply the doco should state this explicitly.

 For example I hope Borland -- and other vendors --
will provide a switch "Ignore access control" and compile
my code without any access checking while I'm debugging nastier
problems. I HATE commenting out "private:" and rebuilding
everything just to add a single debugging line :-)


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <3u75b4$e37@metro.ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au (John Max Skaller) says:
>
>In article <1995Jul7.204804.4882@nlm.nih.gov>,
>Bob Kline <bkline@cortex.nlm.nih.gov> wrote:
>>: >
>>: >BC++ is wrong.
>>
>>: No, BC++ is not wrong. The information provided is incomplete: BC++
>>: generates a warning.
>>:      -- Pete
>>
>>This was made an error back in 1989 when Cfront 2.0 was released.  I
>>believe a diagnostic is required here (not just a warning).
>
>        Borland is free to state certain warnings are diagnostic
>error messages and compile the program anyhow. For the compiler
>to comply the doco should state this explicitly.

Where in the WP does it say this? It is definitely not a requirement
in the C standard, nor, as far as I know, a requirement in the current C++
working paper.

In article <3u97fl$6c7@druid.borland.com>, pete@borland.com (Pete Becker) says:
>
>In article <3u75b4$e37@metro.ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au (John Max Skaller) says:
>>
>>In article <1995Jul7.204804.4882@nlm.nih.gov>,
>>Bob Kline <bkline@cortex.nlm.nih.gov> wrote:
>>>: >
>>>: >BC++ is wrong.
>>>
>>>: No, BC++ is not wrong. The information provided is incomplete: BC++
>>>: generates a warning.
>>>:      -- Pete
>>>
>>>This was made an error back in 1989 when Cfront 2.0 was released.  I
>>>believe a diagnostic is required here (not just a warning).
>>
>>        Borland is free to state certain warnings are diagnostic
>>error messages and compile the program anyhow. For the compiler
>>to comply the doco should state this explicitly.
>
>Where in the WP does it say this? It is definitely not a requirement
>in the C standard, nor, as far as I know, a requirement in the current C++
>working paper.

Whoops, a bit of a dangling modifier their. The "this" in the first sentence
refers to "the doco should state this explicitly". There is no such
requirement.

In article <1995Jul7.204804.4882@nlm.nih.gov>, bkline@cortex.nlm.nih.gov (Bob Kline) says:
>
>Pete Becker (pete@borland.com) wrote:
>: In article <NEERI.95Jul3183753@acme.ethz.ch>, neeri@iis.ee.ethz.ch (Matthias Neeracher) says:
>: >
>: >> 2.
>: >> I had defined a function:
>: >> readWord(unsigned long address, unsigned int& w);
>: >
>: >> I call it by:
>: >> int kk;
>: >> readWord(0L, kk);
>: >
>: >> With BC++, no problem, program run well. With CC, the compiler say:
>: >> "Error: temporary used for non-const unsigned int argument."
>: >> Is it OK in C or C++ standard?
>: >
>: >BC++ is wrong.
>
>: No, BC++ is not wrong. The information provided is incomplete: BC++
>: generates a warning.
>:       -- Pete
>
>This was made an error back in 1989 when Cfront 2.0 was released.  I
>believe a diagnostic is required here (not just a warning).

Yes, a "diagnostic" is required. Note the word you used: you did not say
"an error message" is required. That's because there is no such requirement.
A warning is a diagnostic.

Pete Becker (pete@borland.com) wrote:
: In article <1995Jul7.204804.4882@nlm.nih.gov>, bkline@cortex.nlm.nih.gov (Bob Kline) says:
: >
: >Pete Becker (pete@borland.com) wrote:
: >: In article <NEERI.95Jul3183753@acme.ethz.ch>, neeri@iis.ee.ethz.ch (Matthias Neeracher) says:
: >: >
: >: >> 2.
: >: >> I had defined a function:
: >: >> readWord(unsigned long address, unsigned int& w);
: >: >
: >: >> I call it by:
: >: >> int kk;
: >: >> readWord(0L, kk);
: >: >
: >: >> With BC++, no problem, program run well. With CC, the compiler say:
: >: >> "Error: temporary used for non-const unsigned int argument."
: >: >> Is it OK in C or C++ standard?
: >: >
: >: >BC++ is wrong.
: >
: >: No, BC++ is not wrong. The information provided is incomplete: BC++
: >: generates a warning.
: >:       -- Pete
: >
: >This was made an error back in 1989 when Cfront 2.0 was released.  I
: >believe a diagnostic is required here (not just a warning).

: Yes, a "diagnostic" is required. Note the word you used: you did not say
: "an error message" is required. That's because there is no such requirement.
: A warning is a diagnostic.

You are correct.  I did not say "an error message."  That was implied
by the first sentence ("That was made an error ....").  See, for example,
Stroustrup, Design and Evolution of C++, p. 85 ff., for some background
on when the change was made, the problems which prompted the change,
and the use of the term "error" to describe the condition.

--
/*----------------------------------------------------------------------*/
/* Bob Kline                                       Stream International */
/* bob_kline@stream.com               formerly Corporate Software, Inc. */
/* voice: (703) 522-0820 x-311                      fax: (703) 522-5407 */
/*----------------------------------------------------------------------*/

In article <1995Jul8.212447.14056@nlm.nih.gov>, bkline@cortex.nlm.nih.gov (Bob Kline) says:
>
>Pete Becker (pete@borland.com) wrote:
>: In article <1995Jul7.204804.4882@nlm.nih.gov>, bkline@cortex.nlm.nih.gov (Bob Kline) says:
>: >
>: >Pete Becker (pete@borland.com) wrote:
>: >: In article <NEERI.95Jul3183753@acme.ethz.ch>, neeri@iis.ee.ethz.ch (Matthias Neeracher) says:
>: >: >
>: >: >> 2.
>: >: >> I had defined a function:
>: >: >> readWord(unsigned long address, unsigned int& w);
>: >: >
>: >: >> I call it by:
>: >: >> int kk;
>: >: >> readWord(0L, kk);
>: >: >
>: >: >> With BC++, no problem, program run well. With CC, the compiler say:
>: >: >> "Error: temporary used for non-const unsigned int argument."
>: >: >> Is it OK in C or C++ standard?
>: >: >
>: >: >BC++ is wrong.
>: >
>: >: No, BC++ is not wrong. The information provided is incomplete: BC++
>: >: generates a warning.
>: >:       -- Pete
>: >
>: >This was made an error back in 1989 when Cfront 2.0 was released.  I
>: >believe a diagnostic is required here (not just a warning).
>
>: Yes, a "diagnostic" is required. Note the word you used: you did not say
>: "an error message" is required. That's because there is no such requirement.
>: A warning is a diagnostic.
>
>You are correct.  I did not say "an error message."  That was implied
>by the first sentence ("That was made an error ....").  See, for example,
>Stroustrup, Design and Evolution of C++, p. 85 ff., for some background
>on when the change was made, the problems which prompted the change,
>and the use of the term "error" to describe the condition.

An error in code does not require an error message. It requires only a
diagnostic, that is, a message to the user telling them that they have
done something wrong. The compiler is then free to do whatever the
implementor chooses, including using a sensible construct that makes the
code work in the way the writer probably intended. That is what BC++ does,
and that is perfectly consistent with the requirements of the language
definition.

Pete Becker (pete@borland.com) wrote:
: In article <1995Jul8.212447.14056@nlm.nih.gov>, bkline@cortex.nlm.nih.gov (Bob Kline) says:
: >
: >Pete Becker (pete@borland.com) wrote:
: >: In article <1995Jul7.204804.4882@nlm.nih.gov>, bkline@cortex.nlm.nih.gov (Bob Kline) says:
: >: >
: >: >Pete Becker (pete@borland.com) wrote:
: >: >: In article <NEERI.95Jul3183753@acme.ethz.ch>, neeri@iis.ee.ethz.ch (Matthias Neeracher) says:
: >: >: >
: >: >: >> 2.
: >: >: >> I had defined a function:
: >: >: >> readWord(unsigned long address, unsigned int& w);
: >: >: >
: >: >: >> I call it by:
: >: >: >> int kk;
: >: >: >> readWord(0L, kk);
: >: >: >
: >: >: >> With BC++, no problem, program run well. With CC, the compiler say:
: >: >: >> "Error: temporary used for non-const unsigned int argument."
: >: >: >> Is it OK in C or C++ standard?
: >: >: >
: >: >: >BC++ is wrong.
: >: >
: >: >: No, BC++ is not wrong. The information provided is incomplete: BC++
: >: >: generates a warning.
: >: >:       -- Pete
: >: >
: >: >This was made an error back in 1989 when Cfront 2.0 was released.  I
: >: >believe a diagnostic is required here (not just a warning).
: >
: >: Yes, a "diagnostic" is required. Note the word you used: you did not say
: >: "an error message" is required. That's because there is no such requirement.
: >: A warning is a diagnostic.
: >
: >You are correct.  I did not say "an error message."  That was implied
: >by the first sentence ("That was made an error ....").  See, for example,
: >Stroustrup, Design and Evolution of C++, p. 85 ff., for some background
: >on when the change was made, the problems which prompted the change,
: >and the use of the term "error" to describe the condition.

: An error in code does not require an error message. It requires only a
: diagnostic, that is, a message to the user telling them that they have
: done something wrong. The compiler is then free to do whatever the
: implementor chooses, including using a sensible construct that makes the
: code work in the way the writer probably intended. That is what BC++ does,
: and that is perfectly consistent with the requirements of the language
: definition.

"The C++ Programming Language, 2nd ed.," Reference Manual appendix,
r.13.2, Argument Matching (p. 589) states that "a temporary may not
be used to initialize a non-const reference."  The compiler is therefore
doing something which the language definition says it may not do.
(Unless, of course, the compiler is violating r.8.4.3, which says
the compiler can only make the reference refer to the initializer
passed to the function "if the initializer for a reference to type
T is an lvalue of type T or of a type derived from T for which T is
an accessible base," which is not the case for the thread's example.)

--
/*----------------------------------------------------------------------*/
/* Bob Kline                                       Stream International */
/* bob_kline@stream.com               formerly Corporate Software, Inc. */
/* voice: (703) 522-0820 x-311                      fax: (703) 522-5407 */
/*----------------------------------------------------------------------*/

In article <NEERI.95Jul3183753@acme.ethz.ch>, neeri@iis.ee.ethz.ch (Matthias Neeracher) says:
>
>> 2.
>> I had defined a function:
>> readWord(unsigned long address, unsigned int& w);
>
>> I call it by:
>> int kk;
>> readWord(0L, kk);
>
>> With BC++, no problem, program run well. With CC, the compiler say:
>> "Error: temporary used for non-const unsigned int argument."
>> Is it OK in C or C++ standard?
>
>BC++ is wrong.

No, BC++ is not wrong. The information provided is incomplete: BC++
generates a warning.
 -- Pete

Pete Becker (pete@borland.com) wrote:
: In article <NEERI.95Jul3183753@acme.ethz.ch>, neeri@iis.ee.ethz.ch (Matthias Neeracher) says:
: >
: >> 2.
: >> I had defined a function:
: >> readWord(unsigned long address, unsigned int& w);
: >
: >> I call it by:
: >> int kk;
: >> readWord(0L, kk);
: >
: >> With BC++, no problem, program run well. With CC, the compiler say:
: >> "Error: temporary used for non-const unsigned int argument."
: >> Is it OK in C or C++ standard?
: >
: >BC++ is wrong.

: No, BC++ is not wrong. The information provided is incomplete: BC++
: generates a warning.
:  -- Pete

This was made an error back in 1989 when Cfront 2.0 was released.  I
believe a diagnostic is required here (not just a warning).

--
/*----------------------------------------------------------------------*/
/* Bob Kline                                       Stream International */
/* bob_kline@stream.com               formerly Corporate Software, Inc. */
/* voice: (703) 522-0820 x-311                      fax: (703) 522-5407 */
/*----------------------------------------------------------------------*/

This article may be something on C standard.

Despite the user-friendly environment of BC++, the BC++ compiler seem to fit all the
examples and all the ability of C++ discussed in many C++ reference books, such
exception, type conversion......
Other compiler such CC (AT&T CC) in UNIX seem to have many constraint on
reference data type, exception, signed, data type conversion  .... even in source program
format.
Let me give some examples:
******************************************************
1.



#include <...something...>
#include "mtype.h"     // define some new data type, class ect.
#include "kkkk.h"
#include "bbbb.h"
{
.......
}

The problem is: sometimes in some programs, the compiler can not remember the data
type defined in "mtype.h" or "kkkk.h", but after I add empty line between those
directive line, absolutely no problem any more.
#include <...something...>

#include "mtype.h"

.....

Quite strange, isn't it? I try the same program (after passing the BC++ compiler) with
CC in two UNIX system, one of them is HP CC. More newline, no problem. The
difficult things, these problems not always happen, just for some programs, my
programs are too long to present here. It did really, I guess somebody else in the world
may encounter the similar problems before. I think C language usually should be a format free
language, the problem should not happen and be solved because of empty line.

*********************************************************
2.
I had defined a function:
readWord(unsigned long address, unsigned int& w);

I call it by:
int kk;
readWord(0L, kk);

With BC++, no problem, program run well. With CC, the compiler say:
"Error: temporary used for non-const unsigned int argument."
Is it OK in C or C++ standard?
Why?

Thank you.

zijian.huang@ncl.ac.uk

In article <3t69e9$8uc@whitbeck.ncl.ac.uk>, n4521661 <zijian.huang@ncl.ac.uk> writes:
> Let me give some examples:
> ******************************************************
> 1.



> #include <...something...>
> #include "mtype.h"     // define some new data type, class ect.
> #include "kkkk.h"
> #include "bbbb.h"
> {
> .......
> }

> The problem is: sometimes in some programs, the compiler can not remember the
> data type defined in "mtype.h" or "kkkk.h", but after I add empty line
> between those directive line, absolutely no problem any more.

> #include <...something...>

> #include "mtype.h"

This looks like a bug in the other compiler.

> 2.
> I had defined a function:
> readWord(unsigned long address, unsigned int& w);

> I call it by:
> int kk;
> readWord(0L, kk);

> With BC++, no problem, program run well. With CC, the compiler say:
> "Error: temporary used for non-const unsigned int argument."
> Is it OK in C or C++ standard?

BC++ is wrong. According to 8.5.3 item 5/6 in the draft standard, T1, the type
to which the formal parameter is a reference (unsigned int) must be
reference-compatible with T2, the type of the actual parameter. 8.5.3 item 4
defines reference compatible as: T1 is the same type as T2 or a base class
of T2. unsigned int is neither int nor a base class of int, thus the code is
incorrect.

The C standard doesn't have references.

Matthias

-----
Matthias Neeracher <neeri@iis.ee.ethz.ch> http://err.ethz.ch/members/neeri.html
   "One fine day in my odd past..." -- Pixies, _Planet of Sound_