code cat

이제 대충 프로그램이 동작하기 시작한다. 재구조화는 후우...

어쨌든 현재 동작하는 기능은 다음과 같다.

• OTA Package 정보
• checksum 생성 및 체크

DB 메뉴까지는 만들었는데 이걸 어떻게 구현할지는 아직 미정이다.

자 아래를 보자

문제가 보이는가? 실행하면...

응???

linux에서 gcc 툴체인으로 작업하는 사람들은 위와 같은 반응을 보일텐데...

MSDN에서는 다음과 같이 말하고 있다.  C에서는 함수나 블록의 시작점에 지역변수들은 선언되야 하며, 함수가 선언이 아닌 명령어들을 실행하고 나서는 선언이 들어 올 수 없다고...

// C2143j.c
int main() 
{
    int i = 0;
    i++;
    int j = 0; // C2143 에러
}

그럼 왜 GCC에서는 괜찮은가? 그건 GCC가 위와 같은 코드를 GNU확장으로 허용하기 때문이다.  만약 ANSI나 C89등에 맞추어서 컴파일 되길 원한다면, -pedantic을 flag로 넘겨주면 된다.

typedef struct g_struct {

  int value;

  struct g_struct *next;  //OK

  //gStruct *next  //WRONG!

} gStruct;

알겠지만, 적어도 C에서는 typedef struct 정의 안에서 typedef 된 개체 자체를 reference할 수 없다. 

출처: C언어 펀더멘탈

다음을 보자

와 

의 차이를 쉽게 구별되는가?

두번다 9번을 실행하는 loop이다.

그렇다면, 이 문제를 바꿔서

18<=x<=37 사이의 정수의 갯수는 몇개일까?

헷갈리는데, 정답은 37-18 +1이다.

여기서 1을 더해주는 이유가 대칭 경계(양쪽이 같은 경계법(<,> & =))를 썼기 때문이다.

대신 18 <= x < 37을 한다면, 자신있게

37-18이라고 계산 할 수 있다.

이를 비대칭경계(asynchronous bound)라고 한다.

이는 loop이 몇번 돌지 계산하기 편하게 해 줄 뿐 아니라, 

와 같은 이상한 loop가 돌지 않도록 방지도 해준다.

출처: http://www.technovelty.org/code/why-symbol-visibility-is-good.html

ELF 는 프로그램의 심볼을 관리하는데 있어서 두가지 방법이 있는데, 그중 하나가 symbol binding 이다.

symbol binding에는 크게 다음의 두가지 종류가 있다.

1. Global binding

2. Local binding

Global 바인딩은 현재 빌드되는 file 밖에까지의 visibility scope을 가지고 있다.(즉 외부참조가 가능하다고 할 수 있겠다)

Local 바인딩은 반대로 local scope(static)을 가지고 있다.  추가로 weak의 경우 global가 같으나 overriding이 가능하다고 볼 수 있겠다.

다음의 예를 보자.

sym.c

컴파일 해보면,(참고로 gcc -c는 컴파일/어셈블은 하되, 링크는 하지 말라는 소리이다)

위에서 말한 바와 같이 LOCAL, GLOBAL, WEAK으로 각각 분류된 것을 볼 수 있다.

다음의 경우를 보자.

This is all well and good, but starts breaking down when you want to load many different modules and keep strict API's (such as, say, dynamic libraries!).

Consider that for two files to share a common function, the function must end up with a global visibility.

file1.c

void common(void) { }  

file2.c
extern void common(void);

void func(void) {
     common();
}

file1 & file2는 같은 함수를 공유 하는데, 보면 알겠지만 common의 경우 함수 내부에서만 사용되고 있어, 외부로 노출 할 필요가 없는 함수이다.
 
컴파일 후 내용을 보면 다음과 같다.

앞서 말했듯이, common의 경우 외부로 노출할 필요가 없음에도 GLOBAL 바인딩되어 있는 것을 볼 수 있다.  
링킹도 잘 되고 동작성에 문제 없으나, 이렇게 외부로 노출 될 필요가 없는 경우를 대비해 ELF는 심볼에 대한 visibility를 제공한다.
이 visibility에는 default, protected, hidden 혹은 internal이 있다.
 
가장 안전한 방법으로는 전부 hidden으로 세팅하고(-fvisibility=hidden) 필요 시에,
file1.c
void common_but_not_part_of_api(void) { }
file2.c
extern void common_but_not_part_of_api(void);

void  __attribute__((visibility("default"))) api_function(void) {
      common_but_not_part_of_api();
}
 
 
$ gcc -fvisibility=hidden -shared -fPIC  -o library file1.c file2.c
$ readelf --syms ./library
Symbol table '.symtab' contains 55 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
    48: 000003cc     5 FUNC    LOCAL  HIDDEN   12 common
    54: 000003d4    29 FUNC    GLOBAL DEFAULT  12 func
 
 

이렇게 되면 dynamic loader는 더 이상 common쪽에 접근을 허용치 않는다.

참고로 이러한 방식은 퍼포먼스 향상에도 도움을 준다.  보통 심볼이 override됐을 때, dynamic loader가 function을 제대로 가리킬 수 있도록 컴파일러는 program lookup table(PLT)를 생성해야 한다.  그러나 위와 같이 한다면 PLT 생성을 생략 할 수 있다.

git이 쓰다가 꼬이면 에라씨! 하고

등을 날릴 때가 있는데, 실행하고 나서 앗차!! 할 때가 있다.

이럴 땐 침착하게 다음과 같이 커맨드를 날리자.

무언가 history가 쫘악 뜬다. 여기서 내용을 보면 방금 날린 git reset에 대한 내용이 있다.

그럼 바로 그 전에 걸로 돌아가보자.

오! 된다. 이제 reset잘못했다가 절망하지 말자.