SQL 고수준 키워드 바인딩 보완 + 실동작 왕복 검증
개요
한선씨 커버리지 감사에서 발견된 "고수준 SQL WHERE/SELECT/UPDATE 키워드 미바인딩"
갭을 해소. VM(crownyc.c)에는 구현이 있으나 고수준 컴파일러(hanseonc_high.c)
키워드테이블에 이름이 없어 호출 불가했던 opcode 693(SQL_SELECT)/694(SQL_WHERE)/
695(SQL_UPDATE) 3건을 바인딩하고, 실제 CREATE→INSERT→WHERE→SELECT→COUNT→AVG→
UPDATE→JOIN 파이프라인을 왕복 실행해 기대치와 대조 검증했다.
무엇을 했는지
- hanseonc_high.c 키워드 3건 추가:
SQL선택(693, 아리티3),SQL조건(694,
SQL갱신(695, 아리티4). 기존 450~459는 이미 바인딩되어 있어 손대지 않음.
- hanseonc_rpn.c 키워드 13건 추가: 450~459(SQL계 전체, RPN 쪽엔 전무했음) +
변수 x = f(...) 단일대입으로 소비하면 콜프레임이 오염되어 런타임 에러가 남
(기존 정규매치(692)와 동일 문제, 이미 문서화된 전례를 따름). RPN 모드의
→변수1 →변수2 순차소비만 안전하게 두 값을 받을 수 있어, 완전한 왕복 데모는
RPN으로 작성.
- 실동작 왕복 데모 (
/tmp/cov_sandbox/sql/): 단일컬럼 테이블 생성 → 5행 삽입
- 한계 실측 및 문서화:
</> 등 없음(소스 확인).
- JOIN은 inner-only 등가조인, O(n·m).
- UPDATE는 조건 없이 전체 행 무조건 덮어쓰기 — WHERE와 결합한 조건부 갱신
불가(별도 재구현 필요).
- 문자열 컬럼 사실상 미지원 — SQL계 opcode는 cube_to_int() 원시 핸들 비교만
하고, 한선씨 문자열은 인터닝되지 않아 동일 리터럴도 다른 핸들을 받을 수 있음.
실측: 문자열 3행 삽입 후 SQL개수(=존재하는 값) = 0.
- SQL_SELECT(693) VM 자체에 스택 누수 버그 발견 — case 693이 매 반복마다
push()한 원본 행 값을 정리하지 않고 방치. 반환된 결과수 자체는 정확하지만
스택에 n개 값이 잔류. crownyc.c(VM 코어) 수정은 이번 작업 범위를 벗어나
버그로만 기록, 고치지 않음.
- 빌드/배포: hanseonc_high.c/hanseonc_rpn.c만 변경(VM crownyc.c는 무변경).
tests/run_all.sh 스왑 전/후 모두 99/107 통과(변동 없음).관련 파일
/Users/ef/CrownyOS/crownyc/hanseonc_high.c— 키워드테이블(693~695 신규)/Users/ef/CrownyOS/crownyc/hanseonc_rpn.c— 키워드테이블(450~459, 693~695 신규)/Users/ef/CrownyOS/crownyc/pkg/hanseonc_high.c— 동기화본/Users/ef/CrownyOS/crownyc/docs/한선씨-P2보완-20260710/SQL검증.md— 상세 검증 로그/tmp/cov_sandbox/sql/*.한선— 왕복 데모 소스(roundtrip.한선, sql_rpn.rpn.한선,
잔여 이슈
crownyc.ccase 693(SQL_SELECT) 스택 누수 버그 — 후속 수정 과제로 남김.- 다중 컬럼(레코드 기반) SQL_INSERT(450) 조합 왕복은 검증 범위 밖(단일 스칼라
- 조건부 UPDATE(WHERE+UPDATE 결합)는 현재 opcode 조합으로 직접 지원 안 됨 —