A probe into C language and memory model

#include <stdio.h> #include <string.h>int main () {    long long int a = 2<<30;    Char string[] = "Hello china1!";    Char string2[] = "Hello china2!";    if (0==strcmp (string,string2))    {        printf (string);        printf ("\ n");    }    else    {        printf ("Not match!\n");    }    printf ("A =%u\n", a);    printf ("A =%d\n", a);    Char c[] = {' I ', ' ', ' a ', ' m ', ' ', ' l ', ' I ', ' u ', ' k ', ' u ', ' n '};    printf (c);    return 0;}

　　

The C language string does not have a terminator, and the printed result is not predictable. This should be related to the operating system's memory model for the following reasons: The Windows GCC compilation printing results are:

Not

match!a = 2147483648a = -2147483648i am Liukunhello china2!

The results of the Linux GCC compilation print are:

Not match!
A = 2147483648
A =-2147483648
I am Liukunliukun

I don't know why Hello China2 is connected to I am liukun in memory. Disassembly of the code is very messy and difficult to read. ASCII Code table:

ASCII Code		Character		ASCII Code		Character		ASCII Code		Character		ASCII Code		Character
Decimal	16 Rounding			Decimal	16 Rounding			Decimal	16 Rounding			Decimal	16 Rounding
032	20			15W	38	8		080	50	P		104	68	H
033	21st	!		057	39	9		081	51	Q		105	69	I
034	22	"		058	3 A	:		082	52	R		106	6A	J
035	23	#		059	3 b	;		083	53	S		107	6B	K
036	24	$		060	3C	<		084	54	T		108	6C	L
037	25	%		16P	3D	=		085	55	U		109	6D	M
038	26	&		062	3E	>		18W	56	V		110	6E	N
039	27	‘		063	3F	?		18V	57	W		111	6F	O
040	28	(		064	40	@		088	58	X		112	70	P
14P	29	)		16T	41	A		089	59	Y		113	71	Q
042	2 A	*		066	42	B		090	5 A	Z		114	72	R
043	2 b	+		16V	43	C		091	5B	[		115	73	S
24v	2 C	,		068	44	D		092	5C	\		116	74	T
045	The	-		16X	45	E		093	5D	]		117	75	U
046	2E	.		070	46	F		094	5E	^		118	76	V
047	2F	/		071	47	G		095	5F	_		119	77	W
048	30	0		072	48	H		096	60	`		120	78	X
049	31	1		073	49	I		19V	61	A		121	79	Y
050	32	2		074	4 A	J		098	62	B		122	7A	Z
051	33	3		075	4 b	K		099	63	C		123	7B	{
052	34	4		17W	4C	L		100	64	D		124	7C	|
053	35	5		077	4D	M		101	65	E		125	7D	}
054	36	6		078	4E	N		102	66	F		126	7E	~
055	37	7		079	4F	O		103	67	G		127	7F	Del

"Note" Small terminal mode so-called small-end mode (Little-endian), refers to the high-byte data is stored in the high address of memory, and the low byte of data is kept in the low memory address, this storage mode will address the high-low and data-bit rights effectively combined, higher-address part of the weight, low-address part of the low is consistent with our logical approach. Example: 0000430:e684 6c4e 0100 1800 53ef 0100 0100 00000000440:b484 6c4e 004e ed00 0000 0000 0100 0000 In small-ended mode, the first 32 bits should read this: 4e 6c E6 (assuming int occupies 4 bytes) memory Method: Address growth order is the same as value growth order > objdump-d datatype.exe > Output.txtDisassembly code excerpt:; I am Liukun address arrangement 4014e2:c6 each MOVB $0x49,0x11 (%esp) 4014e7:c6 4014ec movb $0x20,0x12 (%ESP): C6 movb $0x61,0x13 (%esp) 4014f1:c6 6d Movb $0x6d,0x14 (%ESP) 4014f6:c6, Movb $0x20,0x15 (%es P) 4014fb:c6 6c Movb $0x6c,0x16 (%ESP) 401500:c6, Movb $0x69,0x17 (%ESP) 401505:c6-Movb $0x7 5,0x18 (%ESP) 40150A:C6 6b Movb $0x6b,0x19 (%ESP) 40150f:c6 (1a) Movb $0x75,0x1a (%ESP) 401514:C6 1b 6e Movb $0x6e,0x1b (%ESP) .... 40144D:C7 1c 6c MOVL $0X6C6C6548,0X1C (%ESP) end in short, the use of C programming is still more attention, the operation of memory, although cool, but accidentally buried the bug. Say two unused local variable string should be able to be optimized by the compiler, if so the stack will not allocate memory for it, do not know that the Linux under the GCC does not do so.

A probe into C language and memory model