>>8613
>I just want two arrays with nice, clean ASCII values in them to math up, and this was the shortest way (within what I know) to get there
Nigger you did this part just fine previously, see
>>8576
Something that I don't think you understand is how types work. 0x30 (character '0') in char, short, int, uint64, etc., is 0x30. You can print it in hex, binary, decimal, octal, or some other base and it's just a matter of interpretation of the same value. 30 (hex) = 48 (decimal) = 60 (octal) = 110000 (binary). The underlying representation of the value changes, and that's important in many cases, but you don't need an int array to read the ASCII value of a char.
>Concerning what you said about the ASCII int value of "!" on the endians, can you explain that a bit more?
On multi-byte integer types the representation of the values can be either big endian or little endian depending on which one of those bytes is the least significant, that is, if you have a multi-byte integer variable with value 1, where the 1 is written within the memory of the variable. If it's written in the lowest memory address it's little endian and if it's written in the highest memory address then it's big endian. For a 4 byte integer type with an assigned value of 1 the memory layout may look like:
ADDRESS | 0 | 1 | 2 | 3 |
-----------------------------------------
VALUE | 1 | 0 | 0 | 0 |
ADDRESS | 0 | 1 | 2 | 3 |
-----------------------------------------
VALUE | 0 | 0 | 0 | 1 |
>I know an integer VARIABLE occupies 4 bytes (on a 32 or 64 bit machine) but I wasn't yet aware that applied to arrays.
Technically integer size is defined as 'at least 2 bytes' if I remember correctly. There are architectures where it's 2, 4, or 8, or whatever. But don't worry about it for now.
Arrays are just a region of contiguous memory (no gaps in between each element) that can hold a given number of copies of a given type.
int intArray[3]; //it can hold 3 elements of type int, the total size in bytes of the memory area of the array is 3*sizeof(int)
char charArray[3]; //it can hold 3 elements of type char, the total size in bytes of the memory area of the array is 3*sizeof(char)
>>8614
>would C not allocate 4 bytes of memory to each element in an INT array by default then?
Yes
>should I presume that the side of the second array should be something more like sizeof(userinput)*4?
Yes, if you declare it properly with sizeof instead of strlen().
>Was that why you mentioned an overflow issue some posts back?
That was in relation to this
>>8576
for(int i=0; i<1800; i++){
fscanf(Ciphertext, "%d", &cipher[i]);
}
Each element in cipher is 1 byte long and you're telling fscanf() to put a 4 bytes long integer in it. It's going to overflow each element and that's going to work (given that you have a contiguous memory area because it's an array) until it runs out of bounds near the end of the array. The solution to this is to read properly using the right size specifier instead of getting a bigger memory area.
Because your machine is little endian the lowest memory address is going to be written by fscanf(), and then you move to the next memory address and it seems to work. If the machine were big endian the biggest memory address would be written by fscanf(), and then overwritten in the next iteration.