Thread: strlen

Hi all

strlen() defined in string.h return size_t. What is it?

Thank you

oops sorry,
Thank you, I didn't know what is size_t.
If size_t is always unsigned why my compiler don't give me a warning with the following code:

Code:

int len;
len=strlen(string);

Thanks again

int is signed by default.

try:

Code:

unsigned len;

len = strlen(string);

I know I can use unsigned type, but why when using SIGNED type my compiler don't give me an error saying:
Possible lost of data converting unsigned to signed.

Thanks again

Are you using the highest warning level?

The only time a C compiler ever gave me a warning concerning the signedness of a integer was if I compared a signed and unsigned variable.

As far as I can tell, C compilers won't stop you from assigning an unsigned number to a signed variable like len, but that doesn't mean there is no problem in doing that. The integer could overflow if the string were long enough (say 2^15 in length). If this is a problem, use unsigned longs or size_ts.

Thank you guys!

Originally Posted by citizen

As far as I can tell, C compilers won't stop you from assigning an unsigned number to a signed variable like len, but that doesn't mean there is no problem in doing that. The integer could overflow if the string were long enough (say 2^15 in length). If this is a problem, use unsigned longs or size_ts.

The integer might "overflow" in the sense that a positive number might become a negative representation, but the actual bit pattern is guaranteed to be intact. In other words, if you do:

Code:

unsigned int x;
int y;
unsigned int z;

y = x;
z = y;

z will always be equal to x. The bits themselves are preserved. The meaning of those bits is not.

> z will always be equal to x. The bits themselves are preserved. The meaning of those bits is not.

If the bits aren't presented properly, the way they should be, than that is indeed an issue. I'd simply contend that trying to express a number bigger than a container can hold is the very definition of overflow. Whether or not z is equal to x is immaterial. You've merely repeated the solution to the problem.

Originally Posted by citizen

If the bits aren't presented properly, the way they should be, than that is indeed an issue. I'd simply contend that trying to express a number bigger than a container can hold is the very definition of overflow.

Nothing is being expressed. It's just bits. When you stick the bit pattern 11111111 into an unsigned char you get 255. In a signed char, you get -128. The computer doesn't care. The problem exists only in your mind.

Originally Posted by citizen

>The problem exists only in your mind.

Your assertion that human perception doesn't matter when you use a tool is ludicrous. If 1111... means two different things depending on how the computer presents it, and I'm the end-user of some application, then wouldn't I notice getting an incorrect answer? It's suddenly not a bug because you neglected to make the computer print something properly, yet the underlying bit pattern happens to be the same? This whole debacle is semantic.

The point I'm trying to make is that overflow is a operational problem, not a representational one. If you have an 8 bit quantity 255 and add 1 to it, it rolls around to zero. That's overflow.