Trying to compile with g++ on Debian Linux, I get an error when it notes
that I pass a const char* to a function expecting a char*.  It loses the
const qualifier.  I'd expect a warning, but an error?  This compiles
fine with g++ on Red Hat.  I'm even compiling -Wno-cast-qual and
-Wno-error explicitly just to be sure.  Any ideas?

Tim
--
Tim Larson  -  web programming guru
Red 5 Interactive, Inc.  -  www.r5i.com
4549 Fleur Dr.  Des Moines, IA  50321

IMO, your compiler is correct, it must be an error. The only exception to
this rule is when the const char* in question is a string literal - only
then the Standard allows you to pass it to a function that takes a char*.
Otherwise, use a const_cast.

Good luck,
Alexei

Oops.  When you declared that variable const, you were promising
that it wouldn't be modified.  Now you're giving it to a function
which wants to be able to modify it, which is breaking that promise.

FYI, Red Hat 7 ships with an unsupported, broken, deprecated compiler
(gcc 2.96).

Incidentally, "const" doesn't mean the same thing in C as it
does in C++.  Your question appears to be about C++, not C.
Please try not to crosspost unnecessarily.

--

Then is Red Hat's g++ broken?

Which is what I have in this case.  Sorry if that wasn't clear.

--
Tim Larson  -  web programming guru
Red 5 Interactive, Inc.  -  www.r5i.com
4549 Fleur Dr.  Des Moines, IA  50321

I never declared it const.  It's a literal.  Sorry if that wasn't clear.

That's useful to know.  Thanks.

I know that, but I've been using g++ regularly to compile C apps
successfully for over two years.  Obviously there's a compatibility
between the languages, since g++ basically calls gcc with a few extra
options to recognize the source as C++.

I don't think I am, since the "problem" may be either C or C++ related.

--
Tim Larson  -  web programming guru
Red 5 Interactive, Inc.  -  www.r5i.com
4549 Fleur Dr.  Des Moines, IA  50321

Hi Tim,

when a char* is constant then there is a reason for it I think!
If you write the following:
#include <iostream.h>

void func(char *i) {
    strcpy(i, "s");
    }

int main() {
    func((char*)"hallo");
    return 0;

this compiles and link but will never run! The function
would overwrite the "hallo" and the new string is maybe
longer than the old one. In my example this isnt but
my linux box gives me also a "Segmentation fault" and that
is absolut correct cause i try to overwrite a "hard coded constant".
It is possible that such constants are in the text segment of the
programm and this means that the program would by able to
overwrite itself! Not at all should that be correct.

I dont know what your program realy wants to do, but
I think this error is a good one!

In my case, there is no compiler error from the compiler
if I write
...
func("hallo");
...
I dont know why not. Cause such things are a good source of
not trivial debugging problems or?

Bye
Klaus

I think I got it figured out.  We changed the formal parameter type to
be a const char* also.  I hadn't considered this before because my
understanding was reversed.  I'd thought that "promoting" a char* to
const char* would not be allowed.  Actually it's the opposite; making it
const in the function means it can't be modified, which makes it safe
for constant as well as variable strings.

Thanks for all the ideas, especially the pointer that Red Hat's compiler
is sloppy.

--
Tim Larson  -  web programming guru
Red 5 Interactive, Inc.  -  www.r5i.com
4549 Fleur Dr.  Des Moines, IA  50321

There is some degree of compatibility, in that there is a limited
"subset language" (an intersection between C and C++ constructs)
in which you can write programs that are syntactically correct in
both languages and which have identical semantics in both language.
The second claim here, however, is wrong: the GNU compilers have
separate "front ends" for C and C++ (and, for that matter, other
languages as well) that share a common "back end" code-generator.

(The first claim -- "I've been using g++ regularly to compile C
apps successfully" -- is not something I can test or have any intent
to dispute; there are some "C apps" that, whether accidentally or
on purpose, are written in that "subset language" I referred to
above.  It is only the second claim -- "g++ calls gcc" -- that I
am refuting here.)

The "front end" does syntax and semantics analysis, and uses the
"back end" to generate code.  The actual mechanics for gcc and g++
is that there are "drivers" (the "gcc" and "g++" commands), two
completely separate compilers ("cc1" and "cc1plus"), and then a
common assembler ("as" or "gas") and linker.  Those separate
compilers are built by combining the separate front ends with the
common back ends to form two separate programs.  The drivers
invoke the appropriate compiler, whichever that is.  Normally this
is based on the suffix of the file name, i.e., "g++ -c foo.c"
actually invokes the C compiler on foo.c, rather than running
the C++ compiler.

(Use "gcc -v" or "g++ -v" to see that, in fact, gcc or g++ -- it
does not matter which one you use -- invokes the "cc1" compiler
for C sources and the "cc1plus" compiler for C++ sources.  The
difference between the two drivers lies mainly, if not solely, in
the default arguments they supply to the linker.)

In any case, when it comes to "const", this is one of the areas in
which C and C++ semantics are radically different.  For instance,
in C++, you may write:

        const int size = 20;
        char buf[size];
        void f(void) { /* put some code here */ }

while this is illegal in C (even including C99).  If you remove
the "char buf[size];" line, the code is legal in both languages,
but means something different: in C, the "size" variable is an
actual object that is accessible in other C source files, while in
C++, the "size" variable is just a compile-time constant, and is
not accessible from other C++ source files.

In the case in question (const-qualified pointers) the rules for
C and C++ are closer, but still different.  In various ways, C++
gets const right and C gets it wrong -- so if you are used to C++'s
correct treatment of const, and use a C compiler, you may get
annoyed at it. :-)
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc

Why? What's wrong with using a C compiler for C source? Yes, there
are compatibilites between the languages, but also huge differences.
Consider dynamic memory: the AFAIK only way to allocate dynamic
memory that works in both languages is something like

double *d;
d = (double *) malloc(10 * sizeof *d);

which is bad C since the cast is not required and considered bad
style in C, and, I understand, bad C++ because you should be using
new instead.

Gergo

--
I don't want to achieve immortality through my work.  I want to achieve
immortality through not dying.
                -- Woody Allen

Because we've got tons of scripts to automate alot of the process around
here.  We switch between C, C++, and a mixture of the two.  This is the
first time in more than two years that I've seen a problem that's
attributable to the difference between C and C++.

--
Tim Larson  -  web programming guru
Red 5 Interactive, Inc.  -  www.r5i.com
4549 Fleur Dr.  Des Moines, IA  50321

$> man g++
DESCRIPTION
       The C and C++ compilers are integrated; g++ is a script to
       call gcc with options to  recognize  C++.   [...]

That's what I know.  Maybe the man page should be rewritten.  :)  In any
case, thanks for the full scoop on that.

--
Tim Larson  -  web programming guru
Red 5 Interactive, Inc.  -  www.r5i.com
4549 Fleur Dr.  Des Moines, IA  50321

You shouldn't be trying to modify a string literal.

No.  You've been compiling C++ applications which happen not to use
any of the useful features of C++.  

I tried to make it clear that it was not.  It is a C++ problem.  You are
not compiling C, even if your C++ looks very much like C.

--

This is obsolete:

    blp:~(0)$ file -L /usr/bin/{gcc,g++}
    /usr/bin/gcc: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), stripped
    /usr/bin/g++: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), stripped
    blp:~(0)$

GNU is not exactly known for keeping its manpages up-to-date.

--
"When I have to rely on inadequacy, I prefer it to be my own."
--Richard Heathfield

Well, exactly, what I mean is that if you have (and cannot change) a

void legacy_func( char* str );

you should still be able to call it like

legacy_func( "hello" );

That is, of course, you should only do it if you are 100% sure the function
will not try to modify the string. This is not clean, obviously, but
forbidding this kind of code would break too much legacy code, that is why
IMHO the Standard still allows that, and therefore the compiler that chokes
on this code is non-compliant. However, you should not be allowed to write
anything like

const char* str = "hello";
legacy_func( str );

Good luck,
Alexei

From the gcc info pages:

: `g++' is a program that calls GCC with the default language set to C++,
: and automatically specifies linking against the C++ library.  On many
: systems, the script `g++' is also installed with the name `c++'.

Compile the errant code with gcc and the problem will appear to go
away, it needs -Wwrite-strings to flag the problem and even then gcc
will only emit a warning.