{"id":26111,"date":"2022-12-15T14:33:34","date_gmt":"2022-12-15T09:03:34","guid":{"rendered":"https:\/\/jassweb.com\/solved\/solved-passing-string-to-a-function-when-unsigned-int-expected-in-c\/"},"modified":"2022-12-15T14:33:34","modified_gmt":"2022-12-15T09:03:34","slug":"solved-passing-string-to-a-function-when-unsigned-int-expected-in-c","status":"publish","type":"post","link":"https:\/\/jassweb.com\/solved\/solved-passing-string-to-a-function-when-unsigned-int-expected-in-c\/","title":{"rendered":"[Solved] Passing string to a function when unsigned int expected in C"},"content":{"rendered":"

[ad_1]
\n<\/p>\n

\n
\n
<\/div>\n
\n
\n

The whole point of a type<\/em> in a language like C is that it describes some well-defined, useful set of values.<\/p>\n

A value of type unsigned int<\/code> can hold any integer in a range defined by your compiler and processor. This is typically a 32-bit integer, meaning that an unsigned int<\/code> can hold any integer from 0 to 4294967295. But an unsigned int<\/code> can not hold the value 5000000000 (it’s too big), or the value 123.456 (it’s not an integer) or the value “hello, world” (strings aren’t integers).<\/p>\n

A value of type char *<\/code> can hold a pointer to a character anywhere in the usable address space on your computer. So it can hold a pointer to a single character, or it can hold a pointer to a null-terminated array of characters like “hello, world”, or it can hold a NULL pointer. But it is not intended to hold an integer, or a floating-point value.<\/p>\n

Sometimes, under constrained or unusual circumstances, programmers try to bend the rules, by wedging a value of one type into a variable of a different type. Sometimes you can make this work, sometimes you can’t. It’s almost always a significantly bad idea. Even if it can be made to work, it’s often the case that it works properly on one machine, but not others.<\/p>\n

Let’s look more carefully at what you’re doing. (I’m filling in a few details you left out.)<\/p>\n

void expects_unsigned_int(unsigned int);\n<\/code><\/pre>\n
Here we tell the compiler that there’s going to be a function named expects_unsigned_int<\/code> that accepts one argument of type unsigned int<\/code> and returns nothing.<\/p>\n
#include <stdio.h>\n\nint main()\n{\n    expects_unsigned_int(\"some text\");\n}\n<\/code><\/pre>\n
Here we call that function, passing an argument of type char *<\/code>.  We’re in trouble already, of course.  You can’t wedge a char *<\/code> into an unsigned int<\/code> sized slot.  A proper compiler will give you a serious warning, if not an outright error, here.  Mine says<\/p>\n
warning: passing argument 1 of \u2018expects_unsigned_int\u2019 makes integer from pointer without a cast\nexpected \u2018unsigned int\u2019 but argument is of type \u2018char *\u2019\n<\/code><\/pre>\n
These warnings make sense, and are consistent with my explanations so far of what we should and shouldn’t do with types.<\/p>\n
As you may know, a pointer is “just” an address, and on most machines an address is “just” a bit pattern of some size, so you can convince yourself that it ought to be possible to jam a pointer into an integer.  The key question, which we’ll return to in a minute, is whether type unsigned int<\/code> is literally big enough to hold all possible values of type char *<\/code>.<\/p>\n
void expects_unsigned_int(unsigned int val) {\n<\/code><\/pre>\n
Here we begin defining the details of function expects_unsigned_int<\/code>.  Again we say that it accepts one argument of type unsigned int<\/code> and returns nothing.  That’s consistent with the earlier prototype declaration.  All right so far.<\/p>\n
unsigned int* string = 0;\n<\/code><\/pre>\n
Here we declare a pointer of type unsigned int *<\/code> and initialize it to the null pointer.  We don’t really need this intermediate pointer, and in this case it doesn’t matter whether we initialize it, since we’re about to overwrite it.<\/p>\n
string = (unsigned int*) val;\n<\/code><\/pre>\n
Here’s where the trouble begins.  We have an unsigned int value, and we attempt to convert it into a pointer.  Again, this might seem reasonable, since pointers are “just” addresses and addresses are “just” bit patterns.<\/p>\n
The other thing we have is an explicit cast.  In this case, surprisingly, the cast is not really “doing” the conversion from unsigned int<\/code> to unsigned int *<\/code>.  If we wrote the assignment without the cast, like this:<\/p>\n
string = val;\n<\/code><\/pre>\n
the compiler would see an unsigned int<\/code> value on the right-hand side, and a pointer of type unsigned int *<\/code> on the left-hand side, and it would attempt to perform the same conversion implicitly.  But since it’s a dangerous and potentially meaningless conversion, the compiler would warn about it.  Mine says<\/p>\n
warning: assignment makes pointer from integer without a cast\n<\/code><\/pre>\n
But when you write an explicit cast, for most compilers what this means is, “trust me, I know what I’m doing, do this conversion and keep your doubts to yourself, I don’t want to hear any of your warnings.”<\/p>\n
Finally,<\/p>\n
printf(\"%s\", (char*)string);\n<\/code><\/pre>\n
Here we do two things.  First we explicitly convert the unsigned int *<\/code> pointer into a char *<\/code> pointer.  That’s also a questionable conversion, but of a much lesser concern.  On the vast majority of computers today, all pointers (no matter what they point to) have the same size and representation, so a conversion like this is most unlikely to cause any problems.<\/p>\n
And then the second thing we do is, finally, try to print the char *<\/code> pointer using printf<\/code> and %s<\/code>.  As you’ve discovered, it doesn’t always work.  It doesn’t work for me on my computer, either.<\/p>\n
There are computers where it would work, so the answer to your question “Is it possible to do it?” is “Yes, maybe, but.”<\/p>\n
Why didn’t it work for you?  I can’t be sure, but it’s probably for the same reason it didn’t work for me.  On my machine, pointers are 64 bits, but regular ints (including `unsigned int) are 32 bits.  So when we called<\/p>\n
expects_unsigned_int(\"some text\");\n<\/code><\/pre>\n
and attempted to wedge a pointer into an int-sized slot, we scraped off 32 of its 64 bits.  That’s an information-losing transformation, so it’s very likely to be an unrecoverable error.<\/p>\n
Let’s print some additional information, so we can confirm that this is what’s going on.  I encourage you to make these modifications to your program on your computer, so you can see what results you get.<\/p>\n
Let’s rewrite main<\/code> like this:<\/p>\n
int main()\n{\n    char *string = \"some text\";\n    printf(\"string = %p = %s\\n\", string, string);\n    printf(\"int: %d, pointer: %d\\n\", (int)sizeof(unsigned int), (int)sizeof(string));\n    expects_unsigned_int(string);\n}\n<\/code><\/pre>\n
We’re using the printf<\/code> format %p<\/code> to print the pointer.  This will show us a representation of the bit pattern that makes up the pointer value (however big it is), typically in hexadecimal.  We’re also using sizeof()<\/code> to tell us how big ints and pointers are on the machine we’re using.<\/p>\n
Let’s rewrite expects_unsigned_int<\/code> like this:<\/p>\n
void expects_unsigned_int(unsigned int val) {\n    char *string = val;\n    printf(\"val = %x\\n\", val);\n    printf(\"string = %p\\n\", string);\n    printf(\"string = %s\\n\", string);\n}\n<\/code><\/pre>\n
Here we’re printing both the value of val<\/code> as it comes in, and the pointer we recover from it (again, using %p<\/code>).  Also, I’m making string<\/code> of type char *<\/code>, since there was no point in having it unsigned int *<\/code>.<\/p>\n
When I run the modified program, here’s what I get:<\/p>\n
string = 0x101295f20 = some text\nint: 4, pointer: 8\nval = 1295f20\nstring = 0x1295f20\nSegmentation fault: 11\n<\/code><\/pre>\n
Immediately we see several things:<\/p>\n