big endian vs little endian doubts using pointer

There is nothing in your code that depends on the endianess of the system.

This part

(array[0]&0xFF00)|(array[1]&0xFF) 

will always give the same result (here 0xF90C) regardless of endianess.

Endianess only impact the order of bytes stored in memory but once you access data as an integer of correct type, you'll get the same value on little and big endian systems.

BTW - your code has a suspicious cast. You are casting a uint16_t to a uint16_t* (i.e. a pointer). On most systems I would expect a warning like "cast to pointer from integer of different size".

Short answer: The same, endianess does not influence the expression.

Explanation:
In bigendian order, the most signifying byte in a multibyte value is stored at the lowest address,
in little endian order, the mostsignifying byte is stored at the highst address.

So assuming your code example code is compiled in a bigendian environment the memory of your array will contain byte likes this (bytewise, in ascending address order, hexadecimal representation):

• 0xF9
• 0x42
• 0x12
• 0x0C
• 0x07
• 0x33

The same in a little endian environment will end up thus:

• 0x42
• 0xF9
• 0x0C
• 0x12
• 0x33
• 0x07

The accesses to array memebers, combined with the operations, will hence yield in big endian environment:

(0xF924 & (0xFF00))|(0x120C&0xFF)) (0xF900)|(0x0C) 0xF90C 

However, this expression (which accesses the uint16_t members as such and not as bytes), will
in a little endian environment yield exactly the same.

If you read a uint16_t from an array of uint16_t (from whatever index) you will always get the uint16_t which is stored at that index. Bigendian and little endian influence where the most/least signifying byte is stored. But the corresponding compiler "knows" and will generate corresponding code. This in turn usually (i.e. on any platform of 16bit or wider) means to use an appropriate assembler instruction (feeding the lower byte address). The databus and other data access mechanisms see to it that the 16bits get read as they were stored.
I.e. only on an 8bit platform, the generated code will actually be aware of two bytes, which get accessed separatly and expose their byte-addresses.

Whether your expression (of identical value, no matter which endianess) actually is a meaningful address to anything is a non-trivial question. The answer is "do not try, there be dragons", i.e. undefined behaviour. Pointer arithmetic is only for the brave. ;-)

You probably intended to write code which makes the endianess visible. That is possible, but very ugly. Using a union of a three-member-array of 16bits and a six-member-array of 8bits is what I would try. But that would rely on another undefined behaviour (of reading a different union member than the one last written to).