On Sat, 3 Jul 2004 22:04:26 +0000 (UTC), qrczak@knm.org.pl ("Marcin
'Qrczak' Kowalczyk") wrote:

> I don't believe there is any hardware where signed characters are more
> natural. It's only tradition: prehistoric C did not have unsigned types
> at all, and text was 7-bit ASCII anyway, so signed chars by default stuck
> and they became unsigned only where it was necessary (EBCDIC).

There certainly was: the PDP-11, the first machine on which C was
implemented. MOVB to register sign-extends; zero-extending a byte
requires an additional instruction or extra memory (data) accesses, or
both. It's true for ASCII the difference didn't matter, which made it
easier to accept the hardware preference, as well as signed being
consistent with other integers and mildly useful for 'tiny' ones.

And yes once it became "traditional" it was easier to keep it when
feasible, to eliminate one source (of many) of portability issues.


- David.Thompson1 at worldnet.att.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri, 2 Jul 2004 19:49:08 +0000 (UTC), dave@boost-consulting.com
(David Abrahams) wrote:

>rhairgrove_REMOVE_THIS_@bigfoot.com (Bob Hairgrove) writes:
>
>> In reality (i.e. regarding
>> the implementation), there is only signed and unsigned char, of
>> course.
>
>That's not correct.
>
>char is not the same type as signed char, even if char is a signed
>type.  char is always a different type from both signed char and
>unsigned char on a conforming implementation.

I know you're right, and I believe I even said as much in my post,
that char, signed char and unsigned char are three distinct types.

What I intended to say (but it didn't come out right) was that the
typical implementation will choose signed char or unsigned char as the
internal implementation of plain char depending on what the
implementation decides to do with it, or depending on how we have set
the compiler switches (unless we have three-state char now).

Am I correct in concluding that a standard conforming implementation
should complain when a function expects a char argument and I pass
either signed char or unsigned char, regardless of how I have
instructed the compiler to behave with regard to the sign of plain
char (I know, or assume, that compiler switches have nothing to do
with the C++ standard)? I believe that this is not the case with many
popular compilers which claim to be highly conforming, but I might be
wrong.

What was the motivation to have three separate types for char, whereas
there are only int or unsigned int, long or unsigned long, etc., and
the unadorned version of each is automatically signed?

--
Bob Hairgrove
NoSpamPlease@Home.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <tvlbe057cn2brrds0748sh9uo3lfdf7tga@4ax.com>, Bob Hairgrove
<rhairgrove_REMOVE_THIS_@bigfoot.com> writes
>I know you're right, and I believe I even said as much in my post,
>that char, signed char and unsigned char are three distinct types.
>
>What I intended to say (but it didn't come out right) was that the
>typical implementation will choose signed char or unsigned char as the
>internal implementation of plain char depending on what the
>implementation decides to do with it, or depending on how we have set
>the compiler switches (unless we have three-state char now).

What do you mean by a 'three state char'? It is a fundamental principle
of OOP that the programmer should not be concerned with internal
representations. Now to understand the three char types we need to take
a brief excursion back to C.

Viewing a char as the addressable smallest unit of storage, leads to the
desire to use it as a tiny integer type. That implies that there are two
types, signed and unsigned.

However the alternate view of it as storage for a character leads to
having a type that maps onto the underlying hardware's natural
representation of a character. Some hardware naturally uses a signed
format, some an unsigned format and some makes either format equally
natural.

It seemed reasonable to allow 'char' to map to the natural
representation of a character on the underlying system. For a variety of
(good) design reasons, C uses fairly weak typing and expects the
programmer to apply discipline to their work. As long as the programmer
restricts all use of char to character representation there is no
problem. It is only sloppy programming that results in source code that
is vulnerable to the internal representation of a char.

Where a char type is used for something other than representing a
character then the programmer needs to select which of 'signed' and
'unsigned' meets his/her needs.

It is only bad books, poor teaching etc. that leads to source code that
abuses char (now having written that, I wonder how meticulous I was in
my own book for novices :-(


>
>Am I correct in concluding that a standard conforming implementation
>should complain when a function expects a char argument and I pass
>either signed char or unsigned char, regardless of how I have
>instructed the compiler to behave with regard to the sign of plain
>char (I know, or assume, that compiler switches have nothing to do
>with the C++ standard)? I believe that this is not the case with many
>popular compilers which claim to be highly conforming, but I might be
>wrong.

The compiler has no cause to complain if you pass a char type by value
because of the (cursed) implicit conversions). However if you pass by
reference or by pointer it should always issue a diagnostic even if it
then continues with compilation. In addition the wise programmer will
always note that diagnostic and check their source code for erroneous
usage.

>
>What was the motivation to have three separate types for char, whereas
>there are only int or unsigned int, long or unsigned long, etc., and
>the unadorned version of each is automatically signed?

See above. Integer types naturally appear in pairs (signed and
unsigned), a character type is naturally not an integer type. C probably
should have used a different name for a byte, a char and a tiny integer
but in those halcyon days when programmers could be trusted to do the
right thing it did not seem to matter.
:-)



--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sat, 03 Jul 2004 19:16:32 +0000, Francis Glassborow wrote:

> However the alternate view of it as storage for a character leads to
> having a type that maps onto the underlying hardware's natural
> representation of a character. Some hardware naturally uses a signed
> format, some an unsigned format and some makes either format equally
> natural.

I don't believe there is any hardware where signed characters are more
natural. It's only tradition: prehistoric C did not have unsigned types
at all, and text was 7-bit ASCII anyway, so signed chars by default stuck
and they became unsigned only where it was necessary (EBCDIC).

--
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

francis@robinton.demon.co.uk (Francis Glassborow) writes:

[...]

| It seemed reasonable to allow 'char' to map to the natural
| representation of a character on the underlying system. For a variety
| of (good) design reasons, C uses fairly weak typing and expects the
| programmer to apply discipline to their work. As long as the
| programmer restricts all use of char to character representation there
| is no problem. It is only sloppy programming that results in source
| code that is vulnerable to the internal representation of a char.

But C does not have an abstract view of character type -- so that
programers should not concern themselves with the internal
representation of a char even when they restrict all uses of char to
characters.  In particular, it says that if I compare two strings,
using the standard library facilities, the individual characters will
be compared as _unsigned char_ -- even if char is signed on the
particular plateform.  Furthermore, by specification, if I want my code
to be portable from on implementation to another, I can't just say

     char c;
     // ...
     if (isspace(c))
      // ...

No.  I have to decorate the argument with an ugly cast

    if (isspace((unsigned char)c))
      // ...

C does all it can to remind the programmer to worry about the
internal representation of char.  The C++ standard library seems to
carry that baggage over, in a way that is even more inconsistent, with
the standard containers and algorithms :-(

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sat, 03 Jul 2004 01:25:47 +0000, Bob Hairgrove wrote:

> What was the motivation to have three separate types for char, whereas
> there are only int or unsigned int, long or unsigned long, etc., and
> the unadorned version of each is automatically signed?

The motivation for three types was (I guess) that
1. plain char is either signed or unsigned, depending on the implementation,
   where plain int etc. is always signed, so if plain char was an alias
   for one of the others, you couldn't add an overload for signed char and
   unsigned char types if there was already one for plain char,
2. char is generally used to mean characters, signed char and unsigned
   char are used to mean tiny numbers.

The motovation for two possibilities of plain char was that most
implementations traditionally used signed chars, but EBCDIC-based ones
had to use unsigned chars (because English letters are above 128),
so both choices had to be allowed.

BTW, signed chars recently led to a security problem,
http://www.securityfocus.com/archive/1/367615

--
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <1088530470.588887@www.vif.com>,
 denisco@ica.net ("Denis @ Work") wrote:

>Hi,
>
>I eard that I should take my topic here.
>
>I bought a compiler recently which makes perplex in what the ANSI committee
>is doing.
>Making it worst...
>
>Understand one thing : The compiler is there to help programmer in it's
>task, not to dictate how to program.
>
>Here is my issue.

This is a C++ issue, not a C issue.  C does allow this, C++ does not
allow this because of its stricter type checking.  I told you to post on
comp.std.c++

Please show the code so others can see and remove the standard C from
the posting as it does not reflect C but only C++ standards.

Ron

--
  Metrowerks, one of the world   s top 100 companies and influencers
     in the software development industry. - SD Times  May 2004
               http://www.sdtimes.com/2004sdt100.htm

                  Metrowerks, maker of CodeWarrior
Ron Liechty - MWRon@metrowerks.com - http://www.metrowerks.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> First you posted it to both comp.std.c and comp.std.c++ but you never
> even mentioned which language the program is written in and compiled
> as.

I thought it was obvious in C.


> Even worse, for either language, you have not provided enough of the
> source to identify whether you or the compiler vendor is correct.

What is missing ?


> You have shown the compiler diagnostic, and a paraphrase of the
> function definition.  You have not shown us the code that calls the
> function and actually generated the message.  And you have not shown
> us the definition of the values you passed in that function call.

Simple as the error implies here it has been called
char * Dest;
unsigned char * Src;
unsigned MaxCount;

The simplified prototype is as follow:

StringCopy (char * Dest, const char * Src, int MaxCount );


Basically, the compiler is complaining about the "unsigned char *" instead
of a "char *"
The CodeWarrior from metrowerk I bought says that they have (Obligation) to
generate an error in that case.
For starter I do not beleive them.

I beleive that the standard might propose to generate an error but the Mfg
is free to decide between
error and warning in this case. And my point is : It should be a warning not
an error, because the format is compatible. They are both char at
destination, if they where char vs short then I would shut up.

Beside there is an option in that compiler that allows me to enable ANSI
strict type checking and it was turn off at the time.

The question is more like "Are you going to arrest them if they generates a
warning instead of an error"


In other words I have an argument with these guys, about either compiler
should generate an error in that case, or issue a warning.
They are saying that they MUST issue an error. When I ask who forced them
they refer to this group.

Voila!

Denis Co






---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

denisco@ica.net ("Denis @ Work") writes:

> The CodeWarrior from metrowerk I bought says that they have
> (Obligation) to generate an error in that case.  For starter I do
> not beleive them.  I beleive that the standard might propose to
> generate an error but the Mfg is free to decide between error and
> warning in this case.

I can't speak for the C standard, but the C++ standard only says
whether the program is ill-formed and whether a diagnostic is
required.  It doesn't mention "errors" or "warnings". I suppose that
means that they're free to issue warnings for even the worst nonsense.
That said, any compiler which only warns about ill-formed programs
would likely not fare well in the market.

> And my point is : It should be a warning not an error, because
> the format is compatible.

If you're passing a char const* where a char* is expected in a C++
program, it is ill-formed.  It's clear to me that you don't value that
part of the standard, but it's unclear to me why Metrowerks should
share your personal value.  I doubt you'll find another C++ compiler
released in the past 5 years that will not issue a hard error in that
case, whatever options you use.

> They are both char at destination

No, definitely not.  A char and an unsigned char are different types,
even if they have "compatible formats".

> if they where char vs short then I would shut up.
>
> Beside there is an option in that compiler that allows me to enable
> ANSI strict type checking and it was turn off at the time.

AFAICT Metrowerks doesn't have an option to turn off "ANSI strict type
checking", just "ANSI strict checking", which may disable other checks
required by the standard.  Maybe you should consult your fine manual
to see for sure.

Even if it meant "strict type checking", turning the option off
doesn't mean the type checking has to become arbitrarily loose.  For
example, implicit conversions of void* to other pointer types may be
enabled.

> The question is more like "Are you going to arrest them if they
> generates a warning instead of an error"

Not really.  You can't arrest a compiler vendor for poor
quality-of-implementation.  Sometimes I wish I could, though... :)

> In other words I have an argument with these guys, about either
> compiler should generate an error in that case, or issue a warning.
> They are saying that they MUST issue an error. When I ask who forced
> them they refer to this group.

As far as I can tell, they could still issue a "warning" and claim
full standards-conformance, but I think you might be the only customer
thanking them for it.  Most people appreciate errors issued for
const-correctness violations.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

denisco@ica.net ("Denis @ Work") writes:

> The CodeWarrior from metrowerk I bought says that they have
> (Obligation) to generate an error in that case.  For starter I do
> not beleive them.  I beleive that the standard might propose to
> generate an error but the Mfg is free to decide between error and
> warning in this case.

I can't speak for the C standard, but the C++ standard only says
whether the program is ill-formed and whether a diagnostic is
required.  It doesn't mention "errors" or "warnings". I suppose that
means that they're free to issue warnings for even the worst nonsense.
That said, any compiler which only warns about ill-formed programs
would likely not fare well in the market.

> And my point is : It should be a warning not an error, because
> the format is compatible.

If you're passing a char const* where a char* is expected in a C++
program, it is ill-formed.  It's clear to me that you don't value that
part of the standard, but it's unclear to me why Metrowerks should
share your personal value.  I doubt you'll find another C++ compiler
released in the past 5 years that will not issue a hard error in that
case, whatever options you use.

> They are both char at destination

No, definitely not.  A char and an unsigned char are different types,
even if they have "compatible formats".

> if they where char vs short then I would shut up.
>
> Beside there is an option in that compiler that allows me to enable
> ANSI strict type checking and it was turn off at the time.

AFAICT Metrowerks doesn't have an option to turn off "ANSI strict type
checking", just "ANSI strict checking", which may disable other checks
required by the standard.  Maybe you should consult your fine manual
to see for sure.

Even if it meant "strict type checking", turning the option off
doesn't mean the type checking has to become arbitrarily loose.  For
example, implicit conversions of void* to other pointer types may be
enabled.

> The question is more like "Are you going to arrest them if they
> generates a warning instead of an error"

Not really.  You can't arrest a compiler vendor for poor
quality-of-implementation.  Sometimes I wish I could, though... :)

> In other words I have an argument with these guys, about either
> compiler should generate an error in that case, or issue a warning.
> They are saying that they MUST issue an error. When I ask who forced
> them they refer to this group.

As far as I can tell, they could still issue a "warning" and claim
full standards-conformance, but I think you might be the only customer
thanking them for it.  Most people appreciate errors issued for
const-correctness violations.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

denisco@ica.net ("Denis @ Work") writes:

> The CodeWarrior from metrowerk I bought says that they have
> (Obligation) to generate an error in that case.  For starter I do
> not beleive them.  I beleive that the standard might propose to
> generate an error but the Mfg is free to decide between error and
> warning in this case.

I can't speak for the C standard, but the C++ standard only says
whether the program is ill-formed and whether a diagnostic is
required.  It doesn't mention "errors" or "warnings". I suppose that
means that they're free to issue warnings for even the worst nonsense.
That said, any compiler which only warns about ill-formed programs
would likely not fare well in the market.

> And my point is : It should be a warning not an error, because
> the format is compatible.

If you're passing a char const* where a char* is expected in a C++
program, it is ill-formed.  It's clear to me that you don't value that
part of the standard, but it's unclear to me why Metrowerks should
share your personal value.  I doubt you'll find another C++ compiler
released in the past 5 years that will not issue a hard error in that
case, whatever options you use.

> They are both char at destination

No, definitely not.  A char and an unsigned char are different types,
even if they have "compatible formats".

> if they where char vs short then I would shut up.
>
> Beside there is an option in that compiler that allows me to enable
> ANSI strict type checking and it was turn off at the time.

AFAICT Metrowerks doesn't have an option to turn off "ANSI strict type
checking", just "ANSI strict checking", which may disable other checks
required by the standard.  Maybe you should consult your fine manual
to see for sure.

Even if it meant "strict type checking", turning the option off
doesn't mean the type checking has to become arbitrarily loose.  For
example, implicit conversions of void* to other pointer types may be
enabled.

> The question is more like "Are you going to arrest them if they
> generates a warning instead of an error"

Not really.  You can't arrest a compiler vendor for poor
quality-of-implementation.  Sometimes I wish I could, though... :)

> In other words I have an argument with these guys, about either
> compiler should generate an error in that case, or issue a warning.
> They are saying that they MUST issue an error. When I ask who forced
> them they refer to this group.

As far as I can tell, they could still issue a "warning" and claim
full standards-conformance, but I think you might be the only customer
thanking them for it.  Most people appreciate errors issued for
const-correctness violations.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

David Abrahams <dave@boost-consulting.com> writes:

>> They are both char at destination
>
> No, definitely not.  A char and an unsigned char are different types,
> even if they have "compatible formats".

Sorry, there are no unsigned chars involved here.  The rest of what I
wrote stands.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

mwron@metrowerks.com (MW Ron) wrote in message news:<mwron-402AF9.16354230062004@news.newsguy.com>...
             ]

>>First you posted it to both comp.std.c and comp.std.c++ but you
never
>>even mentioned which language the program is written in and compiled
>>as.
>
>
> I thought it was obvious in C.

No, it isn't.
a) You posted this to comp.std.c++.
b) The error in your code is more serious in C++ than it is in C;
therefore (though I can't tell for sure from what you've told us),
you're probably using a C++ compiler.

..
> Simple as the error implies here it has been called
> char * Dest;
> unsigned char * Src;
> unsigned MaxCount;
>
> The simplified prototype is as follow:
>
> StringCopy (char * Dest, const char * Src, int MaxCount );

As you've written it, there's no problem yet, because your first
declarations of Dest, Src, and MaxCount have absolutely no connection
with the second ones. At a minimum, you should provide a simplified
version of the actual code which triggered the message, which
constitutes a complete translation unit. Then, before posting it here,
verify that the simplified version triggers the same error message.

The warning message you're complaining about mentions the exact sizes
of various arrays; if the only things that were involved were
pointers, as you imply, I don't think it would have had any basis for
specifying 1024 and 256. It also mentions unsigned long, a type which
appears nowhere in the code you wrote above.

Your message contains a question about the "unsigned long from
sizeof(TwainInfo.FileName)", yet it's not clear what that comment has
to do with anything else that you've written. I'm going to assume that
you're using an implementation where size_t is a typedef for unsigned
long, and that you attempted to pass that expression in as the third
argument to StringCopy.

> Basically, the compiler is complaining about the "unsigned char *" instead
> of a "char *"

Not quite; it's complaining about (lval) unsigned char[256] vs const
char*. I'm not sure what the compiler means by that notation, which is
why it would have been nice if you'd bothered to display the actual
function call that triggers that message, particularly after having
been explicitly asked to. Here's code that's fairly consistent with
your comments, that I might expect to produce a message such as the
one you've given:

void StringCopy (char * Dest, const char * Src, int MaxCount );

int main()
{
   struct { char FileName[256]; } TwainInfo;
   unsigned char buffer[1024];

   StringCopy(TwainInfo.FileName, buffer, sizeof(TwainInfo.FileName));
   return 0;
}

The problem here is that there is no implicit conversion from unsigned
char* to char*. That would be a minor problem in C; however, C++ makes
heavy use of overloaded functions, and it chooses which overload to
use based upon the actual type. Therefore, the C++ type-checking rules
are much stricter than those in C. If you want to do something like
this, you have to tell the compiler that you know what you're doing,
by performing an explicit conversion from unsigned char* to char*. By
doing so, you're absolving the compiler from any responsibility for
any of the problems that may result.

> The CodeWarrior from metrowerk I bought says that they have (Obligation) to
> generate an error in that case.
> For starter I do not beleive them.

Technically, you're right. The standard says only a few relevant
things about messages like this:

1) If your code contains any diagnosable violations of the rules in
the standard, the implementation must generate at least one diagnostic
message. The contents of that message don't have to say "Error", they
don't have to say "Warning". They do have to be identifiable as
diagnostic messages, but they don't have to correctly describe the
problem; they don't even have to be in any known language.

2) The standard doesn't say anything about "warning" or "error"
messages; there's just diagnostic messages. In practice, the
distinction between an error and a warning message isn't the word
"error" rather than the word "warning". The important difference
between them is the fact that the compiler refuses to compile your
program when it generates an error message.

The standard never requires that a program be rejected, it only
requires that any program containing no violations of any of the rules
it sets up, must be accepted and correctly executed, subject to the
implementation's resource limitations. Your code doesn't qualify for
that guarantee. Therefore, CodeWarrior is allowed to reject your code,
and should reject it, but MetroWerks is lying if they tell you that
the standard requires them to reject it.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

David Abrahams wrote:
>
> I can't speak for the C standard, but the C++ standard only says
> whether the program is ill-formed and whether a diagnostic is
> required.  It doesn't mention "errors" or "warnings". I suppose that
> means that they're free to issue warnings for even the worst nonsense.
> That said, any compiler which only warns about ill-formed programs
> would likely not fare well in the market.
>

Compilers often give warnings for ill-formed programs. The standard
requires "a diagnostic", and says that what constitutes a diagnostic is
implementation-defined. Every compiler I've used defines "a diagnostic"
to be an error message or a warning message.

That's the hook for implementation-specific extensions: often the
warning tells you what the compiler did by way of extension.


--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

David Abrahams <dave@boost-consulting.com> writes:

> David Abrahams <dave@boost-consulting.com> writes:
>
>>> They are both char at destination
>>
>> No, definitely not.  A char and an unsigned char are different types,
>> even if they have "compatible formats".
>
> Sorry, there are no unsigned chars involved here.  The rest of what I
> wrote stands.

Sorry again; it was a char/unsigned char problem.  They are different
types; the code deserves a hard error.  That said, a conforming
compiler implementation could warn.  Before I muddle things any
further, let me get out of this conversation :^)

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

For detail please look at the reply I have given (full) to David.

I think we should continue the discussion from there.

See you soon.
Denis




"James Kuyper" <kuyper@wizard.net> wrote in message
news:8b42afac.0407010410.1664877e@posting.google.com...
> mwron@metrowerks.com (MW Ron) wrote in message
news:<mwron-402AF9.16354230062004@news.newsguy.com>...
>              ]
>
> >>First you posted it to both comp.std.c and comp.std.c++ but you
> never
> >>even mentioned which language the program is written in and compiled
> >>as.
> >
> >
> > I thought it was obvious in C.
>
> No, it isn't.
> a) You posted this to comp.std.c++.
> b) The error in your code is more serious in C++ than it is in C;
> therefore (though I can't tell for sure from what you've told us),
> you're probably using a C++ compiler.
>
> ..
> > Simple as the error implies here it has been called
> > char * Dest;
> > unsigned char * Src;
> > unsigned MaxCount;
> >
> > The simplified prototype is as follow:
> >
> > StringCopy (char * Dest, const char * Src, int MaxCount );
>
> As you've written it, there's no problem yet, because your first
> declarations of Dest, Src, and MaxCount have absolutely no connection
> with the second ones. At a minimum, you should provide a simplified
> version of the actual code which triggered the message, which
> constitutes a complete translation unit. Then, before posting it here,
> verify that the simplified version triggers the same error message.
>
> The warning message you're complaining about mentions the exact sizes
> of various arrays; if the only things that were involved were
> pointers, as you imply, I don't think it would have had any basis for
> specifying 1024 and 256. It also mentions unsigned long, a type which
> appears nowhere in the code you wrote above.
>
> Your message contains a question about the "unsigned long from
> sizeof(TwainInfo.FileName)", yet it's not clear what that comment has
> to do with anything else that you've written. I'm going to assume that
> you're using an implementation where size_t is a typedef for unsigned
> long, and that you attempted to pass that expression in as the third
> argument to StringCopy.
>
> > Basically, the compiler is complaining about the "unsigned char *"
instead
> > of a "char *"
>
> Not quite; it's complaining about (lval) unsigned char[256] vs const
> char*. I'm not sure what the compiler means by that notation, which is
> why it would have been nice if you'd bothered to display the actual
> function call that triggers that message, particularly after having
> been explicitly asked to. Here's code that's fairly consistent with
> your comments, that I might expect to produce a message such as the
> one you've given:
>
> void StringCopy (char * Dest, const char * Src, int MaxCount );
>
> int main()
> {
>    struct { char FileName[256]; } TwainInfo;
>    unsigned char buffer[1024];
>
>    StringCopy(TwainInfo.FileName, buffer, sizeof(TwainInfo.FileName));
>    return 0;
> }
>
> The problem here is that there is no implicit conversion from unsigned
> char* to char*. That would be a minor problem in C; however, C++ makes
> heavy use of overloaded functions, and it chooses which overload to
> use based upon the actual type. Therefore, the C++ type-checking rules
> are much stricter than those in C. If you want to do something like
> this, you have to tell the compiler that you know what you're doing,
> by performing an explicit conversion from unsigned char* to char*. By
> doing so, you're absolving the compiler from any responsibility for
> any of the problems that may result.
>
> > The CodeWarrior from metrowerk I bought says that they have (Obligation)
to
> > generate an error in that case.
> > For starter I do not beleive them.
>
> Technically, you're right. The standard says only a few relevant
> things about messages like this:
>
> 1) If your code contains any diagnosable violations of the rules in
> the standard, the implementation must generate at least one diagnostic
> message. The contents of that message don't have to say "Error", they
> don't have to say "Warning". They do have to be identifiable as
> diagnostic messages, but they don't have to correctly describe the
> problem; they don't even have to be in any known language.
>
> 2) The standard doesn't say anything about "warning" or "error"
> messages; there's just diagnostic messages. In practice, the
> distinction between an error and a warning message isn't the word
> "error" rather than the word "warning". The important difference
> between them is the fact that the compiler refuses to compile your
> program when it generates an error message.
>
> The standard never requires that a program be rejected, it only
> requires that any program containing no violations of any of the rules
> it sets up, must be accepted and correctly executed, subject to the
> implementation's resource limitations. Your code doesn't qualify for
> that guarantee. Therefore, CodeWarrior is allowed to reject your code,
> and should reject it, but MetroWerks is lying if they tell you that
> the standard requires them to reject it.
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
>


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Pete Becker <petebecker@acm.org> writes:

> David Abrahams wrote:
>>
>> I can't speak for the C standard, but the C++ standard only says
>> whether the program is ill-formed and whether a diagnostic is
>> required.  It doesn't mention "errors" or "warnings". I suppose that
>> means that they're free to issue warnings for even the worst nonsense.
>> That said, any compiler which only warns about ill-formed programs
>> would likely not fare well in the market.
>>
>
> Compilers often give warnings for ill-formed programs. The standard
> requires "a diagnostic", and says that what constitutes a diagnostic is
> implementation-defined. Every compiler I've used defines "a diagnostic"
> to be an error message or a warning message.

I said "which _only_ warns" meaning "which doesn't give you an option
to make ill-formedness an error".  I suppose the success of vc6
probably belies that statement too, but I don't think that was an
intentional design decision ;-)

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 30 Jun 2004 23:01:27 +0000 (UTC), denisco@ica.net ("Denis @
Work") wrote:

[snip]
>Simple as the error implies here it has been called
>char * Dest;
>unsigned char * Src;
>unsigned MaxCount;
>
>The simplified prototype is as follow:
>
>StringCopy (char * Dest, const char * Src, int MaxCount );
>
>
>Basically, the compiler is complaining about the "unsigned char *" instead
>of a "char *"
>The CodeWarrior from metrowerk I bought says that they have (Obligation) to
>generate an error in that case.
>For starter I do not beleive them.
>
>I beleive that the standard might propose to generate an error but the Mfg
>is free to decide between
>error and warning in this case. And my point is : It should be a warning not
>an error, because the format is compatible. They are both char at
>destination, if they where char vs short then I would shut up.
>
>Beside there is an option in that compiler that allows me to enable ANSI
>strict type checking and it was turn off at the time.
>
>The question is more like "Are you going to arrest them if they generates a
>warning instead of an error"
>
>
>In other words I have an argument with these guys, about either compiler
>should generate an error in that case, or issue a warning.
>They are saying that they MUST issue an error. When I ask who forced them
>they refer to this group.

As others have pointed out, the Standard requires "a diagnostic"
without specifying whether that is a warning or an error.

For character types, there are actually three separate types: char,
signed char and unsigned char. "char" means "I don't care about the
sign, compiler can do what it wants here". In reality (i.e. regarding
the implementation), there is only signed and unsigned char, of
course. Some compilers (e.g. MSVC, Borland) have a compiler switch
which allow you to specify how plain "char" should be interpreted: as
signed or unsigned.

Maybe this can help. If you really need to, use a cast -- it is
unfortunately necessary in many cases when interfacing with legacy C
code from C++. It might seem silly to you (and I know I have cursed
the creators of the ODBC headers many times for writing this):

/* API declaration data types */
typedef unsigned char   SQLCHAR;

Note that std::string takes a (const)char* in its constructor; there
doesn't seem to be much alternative to using a cast in such
situations.


--
Bob Hairgrove
NoSpamPlease@Home.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Denis @ Work" <denisco@ica.net> wrote in message news:<1088715845.177061@www.vif.com>...
> For detail please look at the reply I have given (full) to David.
>
> I think we should continue the discussion from there.
>
> See you soon.
> Denis

I'm sorry - my newsreader doesn't list any responses by you to David's
messages. Could you find the message on groups.google.com, and give me
an appropriate reference? I can't find it on Google either, but I may
be looking in the wrong place.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

rhairgrove_REMOVE_THIS_@bigfoot.com (Bob Hairgrove) writes:

> In reality (i.e. regarding
> the implementation), there is only signed and unsigned char, of
> course.

That's not correct.

char is not the same type as signed char, even if char is a signed
type.  char is always a different type from both signed char and
unsigned char on a conforming implementation.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi,

I eard that I should take my topic here.

I bought a compiler recently which makes perplex in what the ANSI committee
is doing.
Making it worst...

Understand one thing : The compiler is there to help programmer in it's
task, not to dictate how to program.

Here is my issue.

> > On this topic I have an error which left me stunt...
> > This one is for real.
> >
> > Error   : (10248) function call 'StringCopy({lval} char[1024], {lval}
> > unsigned char[256], unsigned long)' does not match
> >
> > 'StringCopy(char *, const char *, int)'
> >
> > DG_Control.cpp line 265   Name, sizeof(TwainInfo.FileName));
> > Project: DocuPen, Target: DocuPen, Source File: DG_Control.cpp
> > Here is the def:
> >
////////////////////////////////////////////////////////////////////////////
> > typedef           char * PTSTR;
> > typedef const  char * PCTSTR ;
> > int StringCopy (PTSTR Dest, PCTSTR Src, int MaxCount )
> > {
> > ...
> >
> > }
> > Why is that an error?
> >
> > I would understand a warning thaugh, but an error, why?
> >
> > Is it because of the unsigned long from sizeof(TwainInfo.FileName)?
> No.
> > Is it because {lval} char[1024]?
> No.
> > Is it because {lval} unsigned char[256]?
> Yes.  Are you passing in a Str255 type?
> --
> Isaac Wankerl
> Metrowerks

Thanks, But I still persist that should be a warning at most.

The fact that it point to an unsigned instead of a signed while it is
remanining
the same size for the repository makes me perplex.
What prevent then a parameter such as the last one which is unsigned
to define as an error to pass a signed value?

You see now I am stock to use a cast which I hate very very much,
since I have other calls with that mem that also requires it to be unsigned,
but as I the programmer I know it is fine. Now that should be a warning not
an error.

A warning tells a programmer lookout, and should not be hidden
with a cast, it would be like Hiding the warning signs on the road.

An Error is a "sin qua non" Clearly the guy who
decided that it was to be an error lack experiences on the field.

I will say it again if I cast and later on change the repository types, I
will be in much more trouble than this one.
It might even make the code crash.

Unless of-course you have a better suggestion?

Denis




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 29 Jun 2004 19:29:07 +0000 (UTC), denisco@ica.net ("Denis @
Work") wrote in comp.std.c++:

> Hi,
>
> I eard that I should take my topic here.

That's nice, and it might even be correct, but you have done it
incorrectly.

First you posted it to both comp.std.c and comp.std.c++ but you never
even mentioned which language the program is written in and compiled
as.

Even worse, for either language, you have not provided enough of the
source to identify whether you or the compiler vendor is correct.

> I bought a compiler recently which makes perplex in what the ANSI committee
> is doing.
> Making it worst...
>
> Understand one thing : The compiler is there to help programmer in it's
> task, not to dictate how to program.
>
> Here is my issue.
>
> > > On this topic I have an error which left me stunt...
> > > This one is for real.
> > >
> > > Error   : (10248) function call 'StringCopy({lval} char[1024], {lval}
> > > unsigned char[256], unsigned long)' does not match
> > >
> > > 'StringCopy(char *, const char *, int)'
> > >
> > > DG_Control.cpp line 265   Name, sizeof(TwainInfo.FileName));
> > > Project: DocuPen, Target: DocuPen, Source File: DG_Control.cpp
> > > Here is the def:
> > >
> ////////////////////////////////////////////////////////////////////////////
> > > typedef           char * PTSTR;
> > > typedef const  char * PCTSTR ;
> > > int StringCopy (PTSTR Dest, PCTSTR Src, int MaxCount )
> > > {
> > > ...
> > >
> > > }
> > > Why is that an error?

You have shown the compiler diagnostic, and a paraphrase of the
function definition.  You have not shown us the code that calls the
function and actually generated the message.  And you have not shown
us the definition of the values you passed in that function call.

I have no idea what the compiler means by "{lval} char [1024]".  Show
us the definition of the values you pass.

What is the definition of "Name"?  What is the definition of the first
argument, which you haven't even quoted?

Without that additional information, I don't think anyone can express
an informed opinion about whether or not you are right.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]