Length Issue in Char while type casting

[ranjeet.gupta]

Dear All

Please check the below code:

UINT8 MsgLength = 0;

MsgLength = strlen((char *)msg);

if ( MsgLength == 0 || MsgLength 64) {

//Flow A
} else {

//Flow B
}
do you find any issue with the typecasting of the message, will it
create any serious
problem ? As if now I can say that when the message length is more then
256 then it will
fail, apart form this, do any compiler may fail ? looking forward for
the disscussion on this.

Thanks In Advance
Ranjeet Gupta

[Nelu]

ra***********@gmail.com writes:

Dear All

Please check the below code:

UINT8 MsgLength = 0;

UINT8 does not exist in standard C. I will assume it is an 8 bit
unsigned int, although I may be wrong. Your type will probably handle
numbers between 0 and 255.

>
MsgLength = strlen((char *)msg);

strlen returns a size_t. In your case it will be converted to
UINT8, which may not be able to hold the number. If your string has
3000 characters size_t can hold it but UINT8 will not and the value of
the conversion is unknown.

strlen requires a const char *. If you need to cast msg then there's
something probably wrong with your argument.

>
if ( MsgLength == 0 || MsgLength 64) {

//Flow A
} else {

//Flow B
}
do you find any issue with the typecasting of the message, will it
create any serious
problem ?

Who knows, depends on how msg is declared.
--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)

[Eric Sosman]

ra***********@gmail.com wrote On 07/17/06 11:45,:

Dear All

Please check the below code:

UINT8 MsgLength = 0;

MsgLength = strlen((char *)msg);

if ( MsgLength == 0 || MsgLength 64) {

//Flow A
} else {

//Flow B
}
do you find any issue with the typecasting of the message, will it
create any serious
problem ?

I don't think it could create a problem, but it
could hide a problem. For instance, if msg is an int
then the compiler must complain about strlen(msg) but
need not complain about strlen((char*)msg).

In short, the cast is almost certainly useless.

As if now I can say that when the message length is more then
256 then it will
fail, apart form this, do any compiler may fail ? looking forward for
the disscussion on this.

If UINT8 in an unsigned eight-bit type, the code
will misbehave for messages longer than 255 characters,
not 256. Why not use size_t? Or if all you care about
is the branching and you don't really need the length
stored separately, you could use

if (strlen(msg) - 1 64 - 1)

.... relying on the "wrap around" properties of unsigned
integer arithmetic and on the fact that (size_t)-1 is
larger than 63.

--
Er*********@sun.com

[Walter Roberson]

In article <b1*************@ukato.freeshell.org>,
Nelu <sp*******@gmail.comwrote:

>ra***********@gmail.com writes:

> UINT8 MsgLength = 0;

>UINT8 does not exist in standard C. I will assume it is an 8 bit
unsigned int,

> MsgLength = strlen((char *)msg);

>strlen returns a size_t. In your case it will be converted to
UINT8, which may not be able to hold the number. If your string has
3000 characters size_t can hold it but UINT8 will not and the value of
the conversion is unknown.

Earlier, though, you assumed that UINT8 was an unsigned int (of some
particular size.) That being the case, for any particular value
integral returned by strlen, the conversion to UINT8 is well defined,
rater than the result of the conversion being "unknown".

"When a value with integral type is demoted to an unsigned
integer with smaller size, the result is the nonnegative remainder
on division by the number one greater than the largest unsigned
number that can be represented in the type with smaller size."
It happens that in a 2s complement system that this corresponds to
throwing away the upper bits and keeping only the bits that fit within
the smaller unsigned integer, but this value-based definition indicates
the value result for other representation systems as well.

In the example you gave, of 3000, then if UINT8 is 8 bits, the result
would be well defined as being 184 (3000 = 256 * 11 + 184).
Now, of course, if the strlen of msg happened to come out as 2816,
the result of the conversion would be 0 (2816 = 256 * 11), so this
property that the conversion result is well defined does not happen
to be a -useful- property for this code snippet...
--
Prototypes are supertypes of their clones. -- maplesoft

[Nelu]

ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

In article <b1*************@ukato.freeshell.org>,
Nelu <sp*******@gmail.comwrote:

ra***********@gmail.com writes:

UINT8 MsgLength = 0;

UINT8 does not exist in standard C. I will assume it is an 8 bit
unsigned int,

MsgLength = strlen((char *)msg);

strlen returns a size_t. In your case it will be converted to
UINT8, which may not be able to hold the number. If your string has
3000 characters size_t can hold it but UINT8 will not and the value of
the conversion is unknown.

Earlier, though, you assumed that UINT8 was an unsigned int (of some
particular size.) That being the case, for any particular value
integral returned by strlen, the conversion to UINT8 is well defined,
rater than the result of the conversion being "unknown".

"When a value with integral type is demoted to an unsigned
integer with smaller size, the result is the nonnegative remainder
on division by the number one greater than the largest unsigned
number that can be represented in the type with smaller size."
It happens that in a 2s complement system that this corresponds to
throwing away the upper bits and keeping only the bits that fit within
the smaller unsigned integer, but this value-based definition indicates
the value result for other representation systems as well.

In the example you gave, of 3000, then if UINT8 is 8 bits, the result
would be well defined as being 184 (3000 = 256 * 11 + 184).
Now, of course, if the strlen of msg happened to come out as 2816,
the result of the conversion would be 0 (2816 = 256 * 11), so this
property that the conversion result is well defined does not happen
to be a -useful- property for this code snippet...

I should've said useless, but I didn't diferentiate between the words
when I posted. My mistake. Thank you for pointing that out.

--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)