Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > how to deal with the translation from "const char * " to "const unsigned char *"?

Reply
Thread Tools

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

 
 
Michael DOUBEZ
Guest
Posts: n/a
 
      01-29-2007
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
 
Reply With Quote
 
 
 
 
Rolf Magnus
Guest
Posts: n/a
 
      01-29-2007
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.

 
Reply With Quote
 
 
 
 
Michael DOUBEZ
Guest
Posts: n/a
 
      01-29-2007
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

 
Reply With Quote
 
Michael DOUBEZ
Guest
Posts: n/a
 
      01-29-2007
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
 
Reply With Quote
 
Andre Kostur
Guest
Posts: n/a
 
      01-29-2007
"Grizlyk" <(E-Mail Removed)> wrote in news:epkdp5$emk$(E-Mail Removed):

> 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.
 
Reply With Quote
 
Grizlyk
Guest
Posts: n/a
 
      01-29-2007
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


 
Reply With Quote
 
Andre Kostur
Guest
Posts: n/a
 
      01-29-2007
"Grizlyk" <(E-Mail Removed)> wrote in news:epl9fa$f00$(E-Mail Removed):

> 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).
 
Reply With Quote
 
Noah Roberts
Guest
Posts: n/a
 
      01-29-2007
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.
 
Reply With Quote
 
Daniel T.
Guest
Posts: n/a
 
      01-29-2007
In article <epkdp5$emk$(E-Mail Removed)>, "Grizlyk" <(E-Mail Removed)>
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" )
 
Reply With Quote
 
Rolf Magnus
Guest
Posts: n/a
 
      01-29-2007
Andre Kostur wrote:

> "Grizlyk" <(E-Mail Removed)> wrote in news:epkdp5$emk$(E-Mail Removed):
>
>> 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.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
(int) -> (unsigned) -> (int) or (unsigned) -> (int) -> (unsigned):I'll loose something? pozz C Programming 12 03-20-2011 11:32 PM
Casting from const pair<const unsigned char*, size_t>* to constpair<unsigned char*, size_t>* Alex Vinokur C++ 9 10-13-2008 05:05 PM
Printing the range s of unsigned char and unsigned int. Junmin H. C Programming 20 09-20-2007 06:03 AM
unsigned long to unsigned char ashtonn@gmail.com Python 1 06-01-2005 07:00 PM



Advertisments