how to deal with the translation from "const char * " to "const unsigned char *"?

[=?gb2312?B?wNbA1rTzzOzKpg==?=]

i wrote:
-----------------------------------------------------------------------
----------------------------------------
unsigned char * p = reinterpret_cast<unsigned char *>("abcdg");
sizeof(reinterpret_cast<const char *>(p));
-----------------------------------------------------------------------
----------------------------------------

the compiler tells me that "reinterpret_cast from type "const char * "
to type "unsigned char *" casts away constness "

[Kaz Kylheku]

On Jan 28, 11:21 pm, "��大天师" <[e-mail]:

i wrote:-----------------------------------------------------------------------
----------------------------------------
unsigned char * p = reinterpret_cast<unsigned char *>("abcdg");
sizeof(reinterpret_cast<const char *>(p));
-----------------------------------------------------------------------
----------------------------------------

the compiler tells me that "reinterpret_cast from type "const char * "
to type "unsigned char *" casts away constness "

At this point you stop wrestling with the C++ bullshit and just use a
C style cast.

The good old C style cast will implicitly produce the correct
combination of reinterpret_cast and static_cast, without the verbiage
cluttering your code.

Since no typedef names are involved whose meanings could change, the C
style cast is no less safe than the new style cast combination, and is
much more readable.

(If you use the C cast with abstracted types, like casting some A * to
some B *, the danger is that someone may redefine what A and B is, and
the cast will silently continue to work, even though the change may be
such that the conversion has erroneous consequences).

[Gianni Mariani]

��大天师 wrote:

i wrote:
-----------------------------------------------------------------------
----------------------------------------
unsigned char * p = reinterpret_cast<unsigned char *>("abcdg");
sizeof(reinterpret_cast<const char *>(p));
-----------------------------------------------------------------------
----------------------------------------

the compiler tells me that "reinterpret_cast from type "const char * "
to type "unsigned char *" casts away constness "

The compiler is right. "unsigned char *" is non-const and string
literals (like "abcdg") are const.
If you're casting to a "unsigned char *" you need to ask yourself why.
Will it be modified after the cast ? (that would be undefined and toast
your process on some platforms)

It seems like you have a design problem.

[Kai-Uwe Bux]

????? wrote:

i wrote:
-----------------------------------------------------------------------
----------------------------------------
unsigned char * p = reinterpret_cast<unsigned char *>("abcdg");
sizeof(reinterpret_cast<const char *>(p));
-----------------------------------------------------------------------
----------------------------------------

the compiler tells me that "reinterpret_cast from type "const char * "
to type "unsigned char *" casts away constness "

In the code you posted, you do not cast to "const unsigned char *". Try:

unsigned char const * p = static_cast<unsigned char const *>("abcdg");
Best

Kai-Uwe Bux

[Noah Roberts]

Gianni Mariani wrote:

��大天师 wrote:

>i wrote:
-----------------------------------------------------------------------
----------------------------------------
unsigned char * p = reinterpret_cast<unsigned char *>("abcdg");
sizeof(reinterpret_cast<const char *>(p));
-----------------------------------------------------------------------
----------------------------------------

the compiler tells me that "reinterpret_cast from type "const char * "
to type "unsigned char *" casts away constness "

The compiler is right. "unsigned char *" is non-const and string
literals (like "abcdg") are const.

It always intrigues me that such distinction is made in cases like this
yet this is perfectly ok from a legal point of view:

char * x = "I'm const";

[Gianni Mariani]

Noah Roberts wrote:

Gianni Mariani wrote:

....

>
It always intrigues me that such distinction is made in cases like this
yet this is perfectly ok from a legal point of view:

char * x = "I'm const";

Yes, sigh. I think the standard's commitee made a blunder on that one.

This is due to a rather short sighted view that there was a large legacy
code base that would break if that was not allowed. At a guess, I think
this would not be in the standard as an exception if hindsight was
available.

[Grizlyk]

Gianni Mariani wrote:

>>
unsigned char * p = reinterpret_cast<unsigned char *>("abcdg");

the compiler tells me that "reinterpret_cast from type "const char * " to
type "unsigned char *" casts away constness "

The compiler is right. "unsigned char *" is non-const and string literals
(like "abcdg") are const.
If you're casting to a "unsigned char *" you need to ask yourself why.

I think, the following expression
unsigned char * p = static_cast<unsigned char *>( const_cast<char*>
("abcdg") );
is not work because sizeof("type") can be not equal to sizeof("unsigned
type") in theory,

Assuming on your target sizeof("type")==sizeof("unsigned type")

If "p" is _not_ const because there is old library parameter here and you
are shure, that "p" is always using as "const unsigned char *" you can apply
C-style cast
(unsigned char *) ("abcdg")"
or reinterpret_cast<>
unsigned char * p = reinterpret_cast<unsigned char *>( const_cast<char*>
("abcdg") );

else you can create a temporary storage

const char data[]="abcdg";
char buf[sizeof(data)]; strcpy(buf,data);
unsigned char * p = reinterpret_cast<unsigned char *>( buf );

--
Maksim A Polyanin

[Grizlyk]

Grizlyk wrote:

or reinterpret_cast<>
unsigned char * p = reinterpret_cast<unsigned char *>(
const_cast<char*("abcdg") );

And i forget cast via "void*"

unsigned char * p = static_cast<void*("abcdg");

--
Maksim A Polyanin

[Grizlyk]

Grizlyk wrote:

>or reinterpret_cast<>
unsigned char * p = reinterpret_cast<unsigned char *>(
const_cast<char*("abcdg") );

And i forget cast via "void*"

unsigned char * p = static_cast<void*("abcdg");

No, can not, i was wrong, better to do like this

void *const tmp = const_cast<char*>("abcdg");
unsigned char *p = static_cast<unsigned char*>(tmp);

--
Maksim A Polyanin

[Rolf Magnus]

Kaz Kylheku wrote:

>

On Jan 28, 11:21 pm, "��大天师" <[e-mail]:

>i

wrote:-----------------------------------------------------------------------

>---------------------------------------- unsigned char * p =
reinterpret_cast<unsigned char *>("abcdg"); sizeof(reinterpret_cast<const
char *>(p));
-----------------------------------------------------------------------
----------------------------------------

the compiler tells me that "reinterpret_cast from type "const char * "
to type "unsigned char *" casts away constness "

At this point you stop wrestling with the C++ bullshit and just use a
C style cast.

No. At this point you think thrice about letting a pointer to non-const
point to a string literal, and twice about letting a pointer to unsigned
char point to a char.
For the second, there is rarely a reason. For the first, the only reason I
can think of is to deal with legacy code that isn't const correct.

The good old C style cast will implicitly produce the correct
combination of reinterpret_cast and static_cast, without the verbiage
cluttering your code.

No. Rather it produces any combination that will somehow make the target
type from the supplied object. It doesn't magically know if that's the
correct one. So better explicitly tell the compiler which conversion you
actually want.

Since no typedef names are involved whose meanings could change, the C
style cast is no less safe than the new style cast combination, and is
much more readable.

Well, with the C style cast, the OP wouldn't have noticed that he let a
non-const pointer point to something that is const and must not be changed.
The compiler would have silently accepted the erroneous code.

(If you use the C cast with abstracted types, like casting some A * to
some B *, the danger is that someone may redefine what A and B is, and
the cast will silently continue to work, even though the change may be
such that the conversion has erroneous consequences).

It always does silently whatever it takes, so it's always dangerous.

[Michael DOUBEZ]

Gianni Mariani a écrit :

Noah Roberts wrote:

>Gianni Mariani wrote:

...

>>
It always intrigues me that such distinction is made in cases like this
yet this is perfectly ok from a legal point of view:

char * x = "I'm const";

Yes, sigh. I think the standard's commitee made a blunder on that one.

This is due to a rather short sighted view that there was a large legacy
code base that would break if that was not allowed. At a guess, I think
this would not be in the standard as an exception if hindsight was
available.

The standard comitee didn't want to constraint compilers with putting
the array in a rw area.
The compiler is free to put in ro and save some copy time. The array can
even be shared among other part of the program.

That is a reason why casting away the consteness is undefined in this
case and should not be done.

Michael

[Michael DOUBEZ]

Michael DOUBEZ a écrit :

Gianni Mariani a écrit :

>Noah Roberts wrote:

>>Gianni Mariani wrote:

...

>>>
It always intrigues me that such distinction is made in cases like this
yet this is perfectly ok from a legal point of view:

char * x = "I'm const";

Yes, sigh. I think the standard's commitee made a blunder on that one.

This is due to a rather short sighted view that there was a large
legacy code base that would break if that was not allowed. At a
guess, I think this would not be in the standard as an exception if
hindsight was available.

The standard comitee didn't want to constraint compilers with putting
the array in a rw area.
The compiler is free to put in ro and save some copy time. The array can
even be shared among other part of the program.

That is a reason why casting away the consteness is undefined in this
case and should not be done.

In fact, it is legacy code that allowed this writing because string use
to be defaulted as char[] and automaticaly casted to char*.
And the standard changed the type of string to const char[] and thus
strings can now only be automatically casted into const char*.

Michael

[Rolf Magnus]

Michael DOUBEZ wrote:

Gianni Mariani a écrit :

>Noah Roberts wrote:

>>Gianni Mariani wrote:

...

>>>
It always intrigues me that such distinction is made in cases like this
yet this is perfectly ok from a legal point of view:

char * x = "I'm const";

Yes, sigh. I think the standard's commitee made a blunder on that one.

This is due to a rather short sighted view that there was a large legacy
code base that would break if that was not allowed. At a guess, I think
this would not be in the standard as an exception if hindsight was
available.

The standard comitee didn't want to constraint compilers with putting
the array in a rw area.
The compiler is free to put in ro and save some copy time. The array can
even be shared among other part of the program.

What does this have to do with the choice to allow letting a pointer to
non-const point to string literals without a cast?

That is a reason why casting away the consteness is undefined in this
case and should not be done.

Casting away constness isn't undefined. Only writing to an object that was
initially declared const is.

[Michael DOUBEZ]

Rolf Magnus a écrit :

Michael DOUBEZ wrote:

>The standard comitee didn't want to constraint compilers with putting
the array in a rw area.
The compiler is free to put in ro and save some copy time. The array can
even be shared among other part of the program.

What does this have to do with the choice to allow letting a pointer to
non-const point to string literals without a cast?

Why would you be allowed to cast it to not const if not to be able to
modify it ?
And if it is done automatically, there is the risk you modify the string
without remebering it is const.

>

>That is a reason why casting away the consteness is undefined in this
case and should not be done.

Casting away constness isn't undefined. Only writing to an object that was
initially declared const is.

Yes, writing is undefined; that is what I meant.

Michael

[Andre Kostur]

"Grizlyk" <gr******@yandex.ruwrote in news:ep**********@aioe.org:

Gianni Mariani wrote:

>>>
unsigned char * p = reinterpret_cast<unsigned char *>("abcdg");

the compiler tells me that "reinterpret_cast from type "const char *
" to type "unsigned char *" casts away constness "

The compiler is right. "unsigned char *" is non-const and string
literals (like "abcdg") are const.
If you're casting to a "unsigned char *" you need to ask yourself
why.

I think, the following expression
unsigned char * p = static_cast<unsigned char *>(
const_cast<char*>
("abcdg") );
is not work because sizeof("type") can be not equal to
sizeof("unsigned type") in theory,

So? That code is casting pointers-to-object. The pointer size won't
change, regardless of the size of the pointed to object.

[Grizlyk]

Andre Kostur wrote:

>I think, the following expression
unsigned char * p =
static_cast<unsigned char *>
(
const_cast<char*>("abcdg")
);
is do not work because sizeof("type") can be not equal
to sizeof("unsigned type") in theory

So? That code is casting pointers-to-object. The pointer size won't
change, regardless of the size of the pointed to object.

I am not shure (i have no standard) that pointers for all types must have
fixed sizeof() (as "int" for example) or unsigned type must have the same
sizeof() as signed type.

For example there are memory models, where "sizeof(char *_far)==4", but
"sizeof(char *)==2".

Let pointers have fixed sizeof() and sizeof("type")!=sizeof("unsigned
type"). Here pointer arithmetic can be changed, because value of next
pointer (++ptr) is depending from size of object pointer point to.

For example:

int *i=0;
++i; //value of i is 4

char *c=0;
++c; //value of c is 1

//assuming sizeof(int)!=sizeof(unsigned)
unsigned *u=0;
++u; //value of u is 8

--
Maksim A Polyanin

[Andre Kostur]

"Grizlyk" <gr******@yandex.ruwrote in news:ep**********@aioe.org:

Andre Kostur wrote:

>>I think, the following expression
unsigned char * p =
static_cast<unsigned char *>
(
const_cast<char*>("abcdg")
);
is do not work because sizeof("type") can be not equal
to sizeof("unsigned type") in theory

So? That code is casting pointers-to-object. The pointer size won't
change, regardless of the size of the pointed to object.

I am not shure (i have no standard) that pointers for all types must
have fixed sizeof() (as "int" for example) or unsigned type must have
the same sizeof() as signed type.

For example there are memory models, where "sizeof(char *_far)==4",
but "sizeof(char *)==2".

sizeof(char * _far) is a non-standard type, and thus is implementation-
dependant. All Standard pointers-to-object have the same size.

Let pointers have fixed sizeof() and sizeof("type")!=sizeof("unsigned
type"). Here pointer arithmetic can be changed, because value of next
pointer (++ptr) is depending from size of object pointer point to.

Pointer arithmetic has nothing to do with sizeof(T*). But is related to
sizeof(T).

[Noah Roberts]

Michael DOUBEZ wrote:

Rolf Magnus a écrit :

>Michael DOUBEZ wrote:

>>The standard comitee didn't want to constraint compilers with putting
the array in a rw area.
The compiler is free to put in ro and save some copy time. The array can
even be shared among other part of the program.

What does this have to do with the choice to allow letting a pointer to
non-const point to string literals without a cast?

Why would you be allowed to cast it to not const if not to be able to
modify it ?
And if it is done automatically, there is the risk you modify the string
without remebering it is const.

I think you've missed the point. The compiler will not complain about
code that does this:

char * x = "hello";
x[2] = 't';

You'll only get a warning when you try to run the program...if
then...maybe only when you create your release compile with its
optimizations...maybe a customer will find it.

The standard requires that this is ok. It is undefined, even in C where
it comes from, but there can be no diagnostic. Most people would like
to get the usual error about attempting to assign const to non-const
without a cast, but you don't get that in this one special case. Allows
for all sorts of unfortunate errors.

[Daniel T.]

In article <ep**********@aioe.org>, "Grizlyk" <gr******@yandex.ru>
wrote:

Gianni Mariani wrote:

>
unsigned char * p = reinterpret_cast<unsigned char *>("abcdg");

the compiler tells me that "reinterpret_cast from type "const char * " to
type "unsigned char *" casts away constness "

The compiler is right. "unsigned char *" is non-const and string literals
(like "abcdg") are const.
If you're casting to a "unsigned char *" you need to ask yourself why.

I think, the following expression
unsigned char * p = static_cast<unsigned char *>( const_cast<char*>
("abcdg") );
is not work because sizeof("type") can be not equal to sizeof("unsigned
type") in theory,

AFAIK, the above is incorrect. sizeof( "unsigned type" ) always equals
sizeof( "type" )

[Rolf Magnus]

Andre Kostur wrote:

"Grizlyk" <gr******@yandex.ruwrote in news:ep**********@aioe.org:

>Gianni Mariani wrote:

>>>>
unsigned char * p = reinterpret_cast<unsigned char *>("abcdg");

the compiler tells me that "reinterpret_cast from type "const char *
" to type "unsigned char *" casts away constness "

The compiler is right. "unsigned char *" is non-const and string
literals (like "abcdg") are const.
If you're casting to a "unsigned char *" you need to ask yourself
why.

I think, the following expression
unsigned char * p = static_cast<unsigned char *>(
const_cast<char*>
("abcdg") );
is not work because sizeof("type") can be not equal to
sizeof("unsigned type") in theory,

So? That code is casting pointers-to-object. The pointer size won't
change, regardless of the size of the pointed to object.

Well, but using a pointer for accessing an object of a size different from
the pointed-to type might lead to trouble if you aren't prepared for it.

Btw: Different pointer types might also have different sizes.

[Michael DOUBEZ]

Noah Roberts a écrit :

>
I think you've missed the point. The compiler will not complain about
code that does this:

char * x = "hello";
x[2] = 't';

You'll only get a warning when you try to run the program...if
then...maybe only when you create your release compile with its
optimizations...maybe a customer will find it.

The standard requires that this is ok. It is undefined, even in C where
it comes from, but there can be no diagnostic. Most people would like
to get the usual error about attempting to assign const to non-const
without a cast, but you don't get that in this one special case. Allows
for all sorts of unfortunate errors.

OK. My mistake.

Yes, it is misleading and only because K&R C (before 1988) does not have
the const keyword.

Michael

[Ian Collins]

Noah Roberts wrote:

>
I think you've missed the point. The compiler will not complain about
code that does this:

char * x = "hello";
x[2] = 't';

You'll only get a warning when you try to run the program...if
then...maybe only when you create your release compile with its
optimizations...maybe a customer will find it.

The standard requires that this is ok. It is undefined, even in C where
it comes from, but there can be no diagnostic. Most people would like
to get the usual error about attempting to assign const to non-const
without a cast, but you don't get that in this one special case. Allows
for all sorts of unfortunate errors.

I don't think "there can be no diagnostic" is correct. A string literal
has a type of const char*, so the compiler may (and in my opinion
should) issue a diagnostic for "char* x = "hello";"

--
Ian Collins.

[Default User]

Ian Collins wrote:

Noah Roberts wrote:

The standard requires that this is ok. It is undefined, even in C
where it comes from, but there can be no diagnostic. Most people
would like to get the usual error about attempting to assign const
to non-const without a cast, but you don't get that in this one
special case. Allows for all sorts of unfortunate errors.

I don't think "there can be no diagnostic" is correct. A string
literal has a type of const char*, so the compiler may (and in my
opinion should) issue a diagnostic for "char* x = "hello";"

I was going to mention something about this. I believe it was just poor
wording on Noah's part, he meant "can" meaning "possible", I think.
It's possible there will be no diagnostic, because the standard doesn't
require one.


Brian

[Noah Roberts]

Default User wrote:

Ian Collins wrote:

>Noah Roberts wrote:

>>The standard requires that this is ok. It is undefined, even in C
where it comes from, but there can be no diagnostic. Most people
would like to get the usual error about attempting to assign const
to non-const without a cast, but you don't get that in this one
special case. Allows for all sorts of unfortunate errors.

I don't think "there can be no diagnostic" is correct. A string
literal has a type of const char*, so the compiler may (and in my
opinion should) issue a diagnostic for "char* x = "hello";"

I was going to mention something about this. I believe it was just poor
wording on Noah's part, he meant "can" meaning "possible", I think.
It's possible there will be no diagnostic, because the standard doesn't
require one.

Actually, I assumed it was explicitly stated not to since none do. I
couldn't find the place in the standard that says it is ok not to
actually.

[Ian Collins]

Noah Roberts wrote:

Default User wrote:

>>Ian Collins wrote:

>>>Noah Roberts wrote:

>>>>The standard requires that this is ok. It is undefined, even in C
where it comes from, but there can be no diagnostic. Most people
would like to get the usual error about attempting to assign const
to non-const without a cast, but you don't get that in this one
special case. Allows for all sorts of unfortunate errors.

I don't think "there can be no diagnostic" is correct. A string
literal has a type of const char*, so the compiler may (and in my
opinion should) issue a diagnostic for "char* x = "hello";"

I was going to mention something about this. I believe it was just poor
wording on Noah's part, he meant "can" meaning "possible", I think.
It's possible there will be no diagnostic, because the standard doesn't
require one.

Actually, I assumed it was explicitly stated not to since none do. I
couldn't find the place in the standard that says it is ok not to
actually.

The closest is 2.13.4, which defines the type.

Sun CC issues a warning.

--
Ian Collins.

[NagelBagel]

Compilers can issue warnings freely. Also, no compiler is 100%
standards-compliant.

[Ian Collins]

Na********@gmail.com wrote:

Compilers can issue warnings freely. Also, no compiler is 100%
standards-compliant.

Please keep the context of the thread you are replying to.

--
Ian Collins.