IT

" " -> const char *
스택 영역 = 코드 or 스택 영역

code  R
data  R/W
bss   R/W
heap  R/W
stack R/W

char a[] = "하이\n";
char *b = "하이~\n";

*a='1';
*b='1';   <---- 세그먼테이션 오류
                (코드영역을 수정하려고 했기때문에)
printf(const char *)
" " 써도 되고, 문자열의 주소를 넘겨도 된다.

File *fp=fopen("a.txt","r")
OS상에서 a.txt의 메모리 공간을 만들어서
메모리 주소를 File *로 알려준다.

fclose(fp)
OS상에서 어느 파일을 닫아야 할지 모르기 때문에
파일의 메모리 주소를 인자로 받아서 해당 주소의 파일을 닫는다.

printf() -> stdout 표준 출력

0 : stdin   --> 키보드
1 : stdout  --> 화면
2 : stderr  --> 화면

리다이렉션

명령어 > 파일명
ex) ls -al > a.test
명령어 실행 결과를 파일로 출력한다.

명령어 >> 파일명
ex) ls -al >> a.test
명령어 실행 결과를 파일에 추가를 한다.

gcc > g.test
결과) 파일에 기록되지 않는다.

이유) > 기본값은 1> 와 같은데( gcc 1> g.test ),
gcc 에러는 stderr로 출력하기 때문에 기록되지 않는다.
fix) gcc 2> g.test

int main()
{
 int a;
 int *p;
 
 test(&a);
 test3(&p);
}

// 메인문의 인자값을 변경
void test(*p)
{
 *p = 3;
}

// 포인터 p가 가리키는 주소값을 변경할 수 있다.
void test3(**p)
{
 *p = malloc(4);
}

// void 반환형의 insert함수를 만들때
// 더블 포인터를 사용해야한다.

스택 : FILO함수 호출에 사용

큐 : FIFO

스택은 FFFFFFFF 에서 HEAP_END 까지 올라간다.

이렇게 되는 이유는 HEAP과 STACK을 어느 정도 사용할지 모르기 때문이다.

실행파일은 code,data,bss 만 가지고 있다.

Loader가 실행파일의 code,data,bss를 메모리로 복사하고 난 후

Code 영역의 0번지를 실행한다.(code영역의 0번지는 main문이다)

#include <stdio.h>

void test(int d, int e)

{

    int f=6;

    int g=7;

    printf("F=%p\n",&f);

    printf("G=%p\n",&g);

    printf("D=%p\n",&d);

    printf("E=%p\n",&e);

}

int main()

{

    int a=1;

    int b=2;

    int c=3;

    printf("A=%p\n",&a);

    printf("B=%p\n",&b);

    printf("C=%p\n",&c);

    test(4,5);

    return 0;

}

함수 호출 규약(cdecl, stdcall, fastcall)

함수 호출 규약이란 함수가 호출될 때
1. 인자의 전달방법은 어떻게 : 스택으로 이용할것인가? 레지스터를 이용할 것인가
2. 인자의 전달순서는 어떻게 : 오른쪽에서 왼쪽으로 전달할 것인가? 왼쪽에서 오른쪽으로 전달할 것인가?
3. 인자 전달에 이용된 스택의 해제는 어떻게 : 호출한 함수에서 해제할 것인가? 호출된 함수에서 해제할 것인가?
를 정해놓은 규약을 말합니다.

- 영어단어 뜻은, "휘발성의", "순간적인" 이다.

컴파일러의 눈에는 현재 프로그램 소스만 보이기 때문에 변수가 다른 요소에 의해서 변한다는 것을 이해할 수 없다. 초기화된 값만이 변수에 할당되었을 뿐 그 이후로는 값의 변화가 없다고 판단한다. 이러한 이유 떄문에 최적화를 수행하면 메모리로부터 새로운 값을 읽어오지 않고 기존의 초기값으로 프로그램을 수행시킨다.

volatile의 기능적 의미는 캐시사용한함이다. 보통 프로그램이 실행될 떄 속도를 위해 필요한 데이터를 메모리에서 직접 읽어오지 않고 캐시로 부터 읽어온다. 하지만, 하드웨어에 의해서 변경되는 값들은 캐시에서 즉각적으로 반영되지 않으므로 데이터를 캐시로부터 읽어오지 말고 주 메모리에서 직접 읽어오도록 해야한다. 이러한 특성 떄문에 하드웨어가 사용하는 메모리는 volatile로 선언해야 하드웨어에 의해 변경된 값들이 프로그램에 제대로 반영된다.

즉, volatile은 캐시를 사용하지 않는 특성 외에 컴파일러 최적화가 임의로 코드를 변경하는 것을 막을 수 있다.

----------------------------------------------------------------------------------------------------

the_proper_use_of_volatile.pdf

요약하자면 1970년대에 Gordon Bell이 memory-mapped I/O 개념을 소개하면서 compiler optimazation에 의해 의도하지 않은 결과가 발생하기 때문에 이를 막기 위해 volatile의 필요성이 제기됨.

다음과 같은 상황에서 volatile이 필요함.

1. variable의 값이 ‘unstable’한 경우 - 컴파일러도 모르는 어떤 방법으로 값이 변경 (MMIO처럼..)
2. volatile 성격의 data에 대한 write는 ‘observable’하므로 엄격하게 실행되어야 함
3. volatile data에 대한 모든 operation은 소스코드에 나타난 대로 순차적으로 실행되어야 함.

struct test{

   int a;

   char b;

   // short c;

   // char d;

   // char e;

   // short f;

};

int main()

{

  printf("%d\n",sizeof(struct test));

  return 0;

}

// 8byte 출력

// 구조체에 short c 추가 했을 경우에도 8byte

// 다시 구조체에 char d 추가 햇을 경우에는 12byte

 4+4+4 = 12byte

32bit 컴파일러 (4byte)이기 때문에 4byte를 기준으로 최적화 하기 때문에

위의 도표와 같은 메모리 공간에 위치하게 된다.

4+4+1+2 = 11byte

/*

#pragma pack (1) // 1byte로 컴파일 최적화

#pragma pack (4) // 4byte로 컴파일 최적화

*/

#include <stdio.h>

#pragma pack (1)

struct test {

        int a;

        char b;

        //char d;

        //short c;

        //char d;

        //char e;

        //short f;

};

#pragma pack(4)

int main()

{

        printf("%d\n",sizeof(struct test)); 

        return 0;

}