Get_Next_Line

gnl

1. 새롭게 알게 된 점

• 중첩 free 예방 방법

  → free를 한 메모리 주소를 다시 free 하게 되면, 치명적인 오류 발생 이는 해당 메모리 주소가 담겨있는 변수를 NULL로 초기화 함으로써 예방 할 수 있다.

• open, read, write, close함수

    #include <fcntl.h>
    int open(const char *pathname, int flags, ... /* mode_t mode */ );
    /*
    ** pathname : 파일의 경로와 이름을 나타냄
    ** flags : 해당 파일을 어떻게 열지 결정
    ** return value : fd, fail -> negative
    */
    #include <unistd.h>
    ssize_t read(int fd, void* buf, size_t len);
    /*
    ** fd : 파일 디스크립터
    ** buf : 파일에서 읽어들일 버퍼를 결정
    ** len : 얼만큼 읽을지 결정
    ** return value : bytes, fail -> negative
    */
    #include <unistd.h>
    size_t write(int fd, const void *buf, size_t nbytes);
    /*
    ** fd : 파일 디스크립터
    ** buf : 파일에 쓸 버퍼를 결정
    ** nbytes : 얼만큼을 write 할지 결정 
    ** return value : bytes, fail -> negative
    */
    #include <unistd.h>
    int close(int fd);
    /*
    ** fd : 파일 디스크립터
    ** return value : success -> 0, fail -> -1
    */
  

• Tester program(francinette)

  → 일반적으로 기계체점시 Timeout의 한계는 10s, 이는 C언어 기준 많은 시간이다.
  하지만, Tester에는 malloc에 대한, 예외를 잡기위해 부가되는 함수가 많아서(할당을 하는 횟수가 많아짐) 원래는 시간초과가 안뜨는 txt파일이 Tester에서는 Timeout으로 나타나는 경우 발생
  (이는 francinette 기준 paco -tm (second) 커멘드를 사용하여 시간초과 KO의 기준을 늘려 해결가능)
  디펜스 할때는 직접 구현한 TEST main 함수를 사용하여 디펜스
  또한, vscode 터미널에서는 bonus 파일까지 francinette를 이용한 테스트를 할때

  

  위와 같은, 에러가 발생함을 확인할 수 있다 → 테스터의 소스코드를 확인하면 테스터가 잘못된 것 같음
  하지만, 이상하게 Iterm2에서는 해당 에러가 뜨지 않음을 확인
  연결 리스트를 사용하여 구현하면 해당 에러가 없어질 것이라 추정

• OPEN_MAX

  

  위 사진과 같이 OPEN_MAX의 값이 터미널에 따라 다름을 확인
  OPEN_MAX는 환경에 따라 다름을 확인 → 가변적인 자료구조를 사용한 풀이를 해야하는 이유
  꼭 해야하는가? → 리스트를 사용하면, 사용해야할 함수의 개수가 늘어나고, 탐색할 때의 시간 복잡도가 O(n)
  프로그래머가 해당 함수를 잘 이해하고 사용함이 중요하다고 판단하여 OPEN_MAX를 사용한 정적 배열 풀이방법을 채택