This was supposed to take four bytes and turn them into a long int. How do I do this so that the << doesn't turn every byte other than the first one into 'FF'?
Name:
Anonymous2007-02-10 19:54
char temp4[3];
That array is only three characters long.
This was supposed to take four bytes and turn them into a long int.
Have you considered just using a typecast?
FileStart = *(unsigned long *) temp4;
Of course, there's still endian issues to take into consideration.
>That array is only three characters long.
Grrr, I thought array sizes were zero-based...
>Have you considered just using a typecast?
>FileStart = *(unsigned long *) temp4;
>Of course, there's still endian issues to take into consideration.
I had seen the code elsewhere, and I was hoping to avoid the endian issues by using it. It's supposed to work, but I don't know what I got wrong, and I lost the source of the code.
No. a[x] specifies x number of elements.
Access is from 0 to x-1. a[x] lvalues are defined as exactly the same as *(a + x * sizeof(a[0])), and therefore a[-1] accesses the memory location behind a[0].
This is undefined, because C is not a sissy language with bounds checking. a[3] appears to work but writing or reading from it is permitted to make your computer explode.
Name:
102007-02-11 5:45
(actually, *(a + x), because in pointer + x, x is automatically multiplied by the pointer's base type size)
Name:
Anonymous2007-02-11 5:46
>>10
a[3] = "hey";
works fine because it's "hey\0" which is 4 characters, which fit exactly in the four elements array.
Name:
Anonymous2007-02-11 5:51
>>8
Fuckin' wrong. See >>10 to understand why you are so wrong. >>9
see above.
produced the following error under a C++ compiler:
SandBox.cpp(5) : error C2117: 'hey' : array bounds overflow
In C, however, that code will compile, since the compiler performs no bounds checking. Using a memory viewer viewer however, you can clearly see how this is hazardous: 0012FF7C 68 65 79 CC C0 FF 12 00 C9 83 40 heyÌÀÿ..Ƀ@
Notice the abscence of the null byte to terminate the string. Very dangerous indeed.
As a statement, that is illegal. a is an array of char and not an array of char*.
As a declaration, 'char a[x] = "hey"' is the same as 'char *a = "hey"'. No copy is involved, the variable is just a pointer to the string which is in the const data segment.
sizeof() is different, though. For the second, sizeof(a) is sizeof(char*) which is usually 4.
For the first, sizeof(a) is sizeof(char[3]), which is 3, because there are three elements.
Name:
Anonymous2007-02-11 6:08
>>16
Partially wrong.
char a[x] is NOT the same as char* a = "hey";
The first creates the the string of bytes on the stack, including terminating null. The second merely assigns a pointer variable (4 bytes or however wide it is on your system) to a string "hey\0" which will usually be created in the .data section.
The first creates the the string of bytes on the stack, including terminating null.
I checked with GCC and it doesn't generate any obvious memory copies. printf'ing an array declared as being too short does stop it from including the terminating NULL (which that post above didn't imply) and therefore messes up the output, but I only have access to a Linux shell and gcc 3, so no -fdump-tree-* and no stack format I understand to tell me how this works.
Regardless, it's a bad habit to think that the compiler generates copies if your code doesn't try to write to anything. You should know how optimization works.
Name:
Anonymous2007-02-11 6:36
>>17
and don't forget that the char* version is read-only if declared like:
char *s = "stuff";
Name:
Anonymous2007-02-11 21:27
USE UNSIGNED
or you'll get FFFFFFFFFFFs all over the place
Name:
Anonymous2007-02-12 2:03
>>1 - >>21
THIS IS WHY I HATE C/C++
FUCK YOURSELVES
Name:
Anonymous2007-02-12 16:05
>>19
Using msvc6, with no optimizations, a rep movs instruction is generated to copy the bytes to the stack address. Haven't bothered to check with optimization, though it's highly likely the copy will be optimized away if all you're doing is printf'ing it.