Method call (what does it mean)?

The name of an array is a pointer to the first element of the array (and has been since before C++ was considered, it was part of the original C specification) which means that when you write:

nameArray + offset

you are adding a value to a pointer and generating another pointer value to a different element.
For example:

int ar[10];
int *p0 = ar;
int *p1 = ar + 1;

p0 points to the first element of the array, and p1 to the second.
All your code is doing is passing a pointer to the "i-th * 4" element of the array.
And what that actually does is pass a pointer to each 32 bit integer in turn so it can be converted.

It's the equivalent of saying:

z[i] = method(&(param[4 * i]));

"In first round of the for loop is i=0 and z[0]=method(param[4*]) in second round of the for loop is i=1 and z[1]=method(param[4*1]) and so on... At the last round of the for loop is i=15 and z[15]=method(param[4*15]). In each round is the parameter of the mathod() only uint[i], but method() requires array of the 4 uints?

I'm talking about the size of the input variables of method(). Thanks"


OK - each time you enter method(), it gets a pointer to an 8 bit integer, and each time that pointer has moved by four bytes.
4 bytes == 4 * 8 bits == 32 bits == one 32bit integer
So what method is doing is reassembling the four 8bit bytes into a single 32bit integer.
In theory, you can do this a lot simpler, just by casting the pointer:

static uint32_t method(uint8_t *b)
    {
    return *((uint32*)b);
    }

BUT...there are two potential problems with that.
The first is that the 32bit integer pointer will only work if the address in the 8bit pointer is aligned on a 32bit boundary: the address must end with 00 binary. If it isn't (and doesn't) then your will either get odd results, or an application error.

The second is that there are two ways of converting a 32bit number to four 8bit values, depending on how your hardware organises them: "little endian" and "big endian" and that depends on the processor. "Little endian" systems store the least significant 8 bits of the 32 bit number in the lowest numbered byte address, "big endian" systems store the most significant digits in the lowest numbered byte address. Intel and AMD PC processors are "little endian", but not all processors are, so you can't always assume that data from another system will be in the format you expect.

The code you are using doesn't care about the "endianness" of your system, it manually converts it from "little endian" data to a 32bit integer regardless of the system it runs on. So it gets a poiter to teh leastsignificant byte, and buts it in the low 8 bits of the output. Then the next byte goes in the next 8 bits and so on.
So if your input data was in hex bytes 0x12, 0x34, 0x56, 0x78 then the bytes go into an 32 bit integer to produce a hex value: 0x78563412

See what I mean?