423,850 Members | 1,661 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 423,850 IT Pros & Developers. It's quick & easy.

char * vs. const char *

P: n/a
Hi folks

Is it legal for a C compiler that claims to be conforming to the standard
(c89) to issue an error on the following:

char *foo(const char *s)
{
const char *s;
for (s = src; *s && !(((unsigned char)s[0]) & 0x80); s++)

if (*s == c)

return s;

....

}

I get 2 errors when compiling this:

error(212): return value type does not match the function type

error(611): a value of type "const char *" cannot be assigned to an entity
of type "char *"

I'd understand a warning, but an error?

Bye, Jojo
Nov 14 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
Joachim Schmitz wrote:
Is it legal for a C compiler that claims to be conforming to the standard
(c89) to issue an error on the following:
Yes. In fact, a conforming compiler is /obliged/ to diagnose this
code.
char *foo(const char *s)
{
const char *s; [...]
I'd understand a warning, but an error?


There's no distinction between warnings and errors in C89: the
standard requires that "diagnostics" are issued for certain
violations. After such a diagnostic has been issued the compiler is
under no obligation to continue translation.

Jeremy.
Nov 14 '05 #2

P: n/a
Hi Jeremy

"Jeremy Yallop" <je****@jdyallop.freeserve.co.uk> wrote in message
news:sl*******************@maka.cl.cam.ac.uk...
Joachim Schmitz wrote:
Is it legal for a C compiler that claims to be conforming to the standard (c89) to issue an error on the following:
Yes. In fact, a conforming compiler is /obliged/ to diagnose this
code.
char *foo(const char *s)
{
const char *s;

[...]
I'd understand a warning, but an error?


There's no distinction between warnings and errors in C89: the
standard requires that "diagnostics" are issued for certain
violations. After such a diagnostic has been issued the compiler is
under no obligation to continue translation.

Thanks,

Well, unfortunaly the Samba code is full of such things and I have to insert
(char *) all over the place to get it compiled...
If a compiler is allowd to choke on this, it'd be a bug in Samba and I'll
report it as such. Otherwise I'd report it as a bug against our c89...
Jeremy.

Bye, Jojo
Nov 14 '05 #3

P: n/a
Joachim Schmitz <no***********@hp.com> wrote:
Hi folks Is it legal for a C compiler that claims to be conforming to the standard
(c89) to issue an error on the following: char *foo(const char *s)
{
const char *s;
for (s = src; *s && !(((unsigned char)s[0]) & 0x80); s++) if (*s == c) return s; ... } I get 2 errors when compiling this: error(212): return value type does not match the function type error(611): a value of type "const char *" cannot be assigned to an entity
of type "char *" I'd understand a warning, but an error?


The compiler is obligated to emit a diagnostic in this case. Whether
it is a warning or an error is not germane as far as the standard is
concerned.
--
Alex Monjushko (mo*******@hotmail.com)
Nov 14 '05 #4

P: n/a
Joachim Schmitz wrote:
char *foo(const char *s)
{
const char *s;
for (s = src; if (*s == c)

I see an automatic variable and a parameter, both named s,
and external variables named src and c ?
Is that really the code ?

--
pete
Nov 14 '05 #5

P: n/a

On Mon, 16 Feb 2004, Joachim Schmitz wrote:

Is it legal for a C compiler that claims to be conforming to the standard
(c89) to issue an error on the following:

char *foo(const char *s)
{
const char *s;
Most compilers I know will issue a (non-required) diagnostic for
this definition, as it shadows a parameter with the same name.
for (s = src;
Here you will get a (required) diagnostic: 'src' has never been
declared. I don't think any compiler will continue compilation
after this line.
*s && !(((unsigned char)s[0]) & 0x80); s++)
As far as I can tell, this is just a fancier and slightly less
portable way of writing

for (s = src; (*s != 0) && ((unsigned)*s < 0x80u); ++s)

Note that even that cast to 'unsigned' could be dropped, but then
some compilers would give you warnings about comparisons between
signed and unsigned values -- even though in this case, it's
completely intentional.
if (*s == c)
Another mandatory diagnostic here for the undeclared identifier 'c'.
return s;

...

}

I get 2 errors when compiling this:

error(212): return value type does not match the function type
Makes sense. You're trying to return a 'const char *' from a
function that expects to be returning a 'char *'. The other way
around works, of course, because you can legitimately "constify"
just about anything; but converting away 'const' is a Big No-No.
You shouldn't try it.
error(611): a value of type "const char *" cannot be assigned to an entity
of type "char *"
Again, duh. You can't blithely convert away constness, because that
basically destroys the safety of your code. The whole reason to
use 'const' is to protect variables from being changed arbitrarily;
if you could cast that away, then you could get around 'const' with
no repercussions, and it would make bugs that much harder to find.
I'd understand a warning, but an error?


From the C Standard's point of view, that's a quality-of-implementation
issue. Your compiler probably has a way to turn down the warning level;
but it would be much neater (and certainly your boss would thank you)
if you simply changed the code to make it correct in the first place.
At the moment, it looks like a mess.

HTH,
-Arthur

Nov 14 '05 #6

P: n/a
Hi Pete

"pete" <pf*****@mindspring.com> wrote in message
news:40***********@mindspring.com...
Joachim Schmitz wrote:
char *foo(const char *s)
{
const char *s;
for (s = src;
if (*s == c)

I see an automatic variable and a parameter, both named s,
and external variables named src and c ?
Is that really the code ?

No, sorry, if should have been
char * foo (const char *src)
--
pete


Bye, Jojo
Nov 14 '05 #7

P: n/a
Hi Athur

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message
news:Pi***********************************@unix41. andrew.cmu.edu...

On Mon, 16 Feb 2004, Joachim Schmitz wrote:

Is it legal for a C compiler that claims to be conforming to the standard (c89) to issue an error on the following:

char *foo(const char *s)
{
const char *s;
Most compilers I know will issue a (non-required) diagnostic for
this definition, as it shadows a parameter with the same name.

Well, sorry, that was a mistake on my side.
I'd understand a warning, but an error?


From the C Standard's point of view, that's a quality-of-implementation
issue. Your compiler probably has a way to turn down the warning level;
but it would be much neater (and certainly your boss would thank you)
if you simply changed the code to make it correct in the first place.
At the moment, it looks like a mess.

As wrote elswhere in this thread, it isn't my code, it's a snippet from
Samba....
And no, my compiler doesn't have a switch to ignore errors, I can turn down
warnings, but not errors.
The only 'switch' would be a (char *) cast.
HTH,
-Arthur

Bye, Jojo
Nov 14 '05 #8

P: n/a
Joachim Schmitz wrote:

Hi Pete

"pete" <pf*****@mindspring.com> wrote in message
news:40***********@mindspring.com...
Joachim Schmitz wrote:
char *foo(const char *s)
{
const char *s;
for (s = src;

if (*s == c)

I see an automatic variable and a parameter, both named s,
and external variables named src and c ?
Is that really the code ?

No, sorry, if should have been
char * foo (const char *src)


I can only guess that there are more yet undisclosed typos.

If you have copy and paste capability, you should use it.

char * foo (const char *src)
{
const char *s; /* This should not cause a problem */

s = src;
return (char *)s;
/* This cast is needed, to shed the const qualifier */
}

--
pete
Nov 14 '05 #9

P: n/a
In <Pi***********************************@unix41.andr ew.cmu.edu> "Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:

On Mon, 16 Feb 2004, Joachim Schmitz wrote:

Is it legal for a C compiler that claims to be conforming to the standard
(c89) to issue an error on the following:

char *foo(const char *s)
{
const char *s;


Most compilers I know will issue a (non-required) diagnostic for
this definition, as it shadows a parameter with the same name.


Non-required?!?

9 Each parameter has automatic storage duration. Its identifier
is an lvalue, which is in effect declared at the head of the
compound statement that constitutes the function body (and
therefore cannot be redeclared in the function body except in
an enclosed block).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #10

P: n/a

On Tue, 17 Feb 2004, Dan Pop wrote:

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:
On Mon, 16 Feb 2004, Joachim Schmitz wrote:

char *foo(const char *s)
{
const char *s;


Most compilers I know will issue a (non-required) diagnostic for
this definition, as it shadows a parameter with the same name.


Non-required?!?

9 Each parameter has automatic storage duration. Its identifier
is an lvalue, which is in effect declared at the head of the
compound statement that constitutes the function body (and
therefore cannot be redeclared in the function body except in
an enclosed block).


Hmm... I guess a diagnostic is required, then. Maybe I was confusing
this situation with the superficially-similar case in C++, where one
can write

[C++]
class foo {
int i;
void member_fxn();
};

void foo::member_fxn() {
int i;
/* ...'i' now refers to local 'i', not 'this->i' */
}
[/C++]

Anyway, required or not, this diagnostic shouldn't be ignored,
because it's so easy to fix it. ;-)

-Arthur
Nov 14 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.