c - why does a integer type need to be little-endian? -

i curious little-endian , know computers have little-endian method.

so, praticed through program , source below.

int main(){  int flag = 31337; char c[10] = "abcde"; int flag2 = 31337;  return 0;  } 

when saw stack via gdb,

i noticed there 0x00007a69 0x00007a69 .... ... ... .. .... ... 0x62610000 0x00656463 .. ...

so, have 2 questions.

for 1 thing,

how can value of char c[10] under flag?

i expected there value of flag2 in top of stack , value of char c[10] under flag2 , value of flag under char c[10].

like this

7a69 "abcde" 7a69 

second,

i expected value stored in way of little-endian.

as result, value of "abcde" stored '6564636261'

however, value of 31337 wasn't stored via little-endian.

it '7a69'. thought should '697a'

why doesn't integer type conform little-endian?

there confusion in understanding of endianness, stack , compilers.

first, locations of variables in stack may not have code written. compiler free move them around how wants, unless part of struct, example. try make efficient use of memory possible, needed. example having char, int, char, int require 16 bytes (on 32bit machine), whereas int, int, char, char require 12 bytes.

second, there no "endianness" in char arrays. that: arrays of values. if put "abcde" there, values have in order. if use example utf16 endianness come play, since 1 part of codeword (not 1 character) require 2 bytes (on normal 8-bit machine). these stored depending on endianness.

decimal value 31337 0x007a69 in 32bit hexadecimal. if ask debugger show it, show such whatever endianness. way see how in memory dump bytes. 0x69 0x7a 0x00 0x00 in little endian.

also, though little endian popular, it's because x86 hardware popular. many processors have used big endian (sparc, powerpc, mips amongst others) order , (like older arm processors) run in either one, depending on requirements.

there term "network byte order", big endian. relates times before little endian machines became popular.