한선씨 적합성 Top3 수정 (포함하나·오버플로감지·Base64)

개요

적합성 실측감사([[2026-06-21-한선씨-적합성-실측감사]]) 우선수정 Top7 중 #1·#2·#3 착수·완료. 모두 라이브 바이너리 반영 + 회귀 그린 + 윈도우 번들 전파.

#1 포함하나() 신규 빌트인 (boolean 멤버십)

문제: 포함()=인덱스 반환 → 위치0 매칭이 3진 false로 오판(최다빈도 silent오답).

수정(비파괴): 기존 포함(인덱스) 불변, 새 opcode 750 포함하나(참1/거짓-1) 추가.

crownyc.c: VM case 750 STR_CONTAINS(strstr → 참/거짓)

hanseonc_high.c: 빌트인 {"포함하나", 750, 2}

검증: 포함하나("Hello","Hello")=1(참), "xyz"=-1, 만약 분기 정상. 구 포함()=0 유지.

#2 정수 곱셈 오버플로 감지

문제: ±3^24(±141,214,768,240) 초과 곱 → 자연 래핑 silent 오답(10억²=45604504414).

수정: crownyc.c MUL(case 83) 정수분기에 int64 사전판정 → 초과 시 stderr 경고(.toau 출력 불변, 비파괴).

[경고] 정수 곱셈 오버플로: A * B 가 ±141214768240 범위를 넘어 결과가 손상됩니다(자연 래핑)

검증: 100만×100만 경고+래핑, 123456×789 무경고(범위내).

#3 Base64 라이브러리 정정 (절단나눗셈 + UTF-8 바이트)

문제: ① 내장 /·%가 자연반올림이라 비트추출 깨짐("Man"→"TWG", 110/64=2). ② 문자단위 처리라 코드포인트>255 한글 깨짐.

수정: libs/Base64.한선(+std 동기화)

절단나눗셈(opcode 738) 헬퍼 _절단몫/_절단나로 모든 비트 /·% 교체.

UTF-8 바이트 단위 처리: _UTF8바이트들(코드포인트→1~4바이트), _UTF8문자열(역). 인코딩=바이트열, 디코딩=바이트열→문자열.

URL디코딩 길이(문자열)%4 버그도 _절단나(글자수,4)로 정정.

검증(openssl byte-perfect): Man=TWFu, Test123=VGVzdDEyMw==, 안녕=7JWI64WV, 한글왕복="안녕하세요 세계", URL왕복 OK. import 경로도 정상.

적용 범위

• 라이브 mac 바이너리 원자 swap(동일FS 빌드+mv, 백업 crownyc.bak.top3/hanseonc_high.bak.top3). 장수 서비스는 재시작해야 반영.
• 윈도우 번들 exe 재크로스컴파일 + 번들 std/Base64 갱신 + kps 클라우드 재업로드(706KB).
• 회귀 그린: 100/2=50, 팩토리얼5=120, 나눗셈회귀=T, 한글 글자수=5, 정렬 정상.
• 학습 등록: Base64_UTF8_절단나눗셈_인코딩.

2차: #4 맵 센티넬 + 헥스 (이어서 완료)

#4 맵있나() 신규 빌트인 (존재확인)

문제: 맵꺼내 없는키=−1 반환인데 없나() 매크로는 ==−2147483647 체크 → 불일치로 탐지실패. 어떤 센티넬도 정상값과 충돌(값이 −1인 키 구분 불가).

수정(비파괴): 기존 맵꺼내/없나 불변, 새 opcode 751 맵있나(맵,키)(참1/거짓-1) — HASH_GET과 동일 프로빙으로 키 존재만 확인.

crownyc.c: VM case 751 HASH_HAS, hanseonc_high.c: {"맵있나", 751, 2}

검증: 있는키=1, 없는키=−1, 값이−1인키 맵있나=1(센티넬로는 불가능한 정확 존재확인), 만약 분기 정상.

#3 마무리: 헥스인코딩 (해시.한선)

• 문제: _헥스글자(b/16)·b%16 자연반올림 → 헥스([72,101,108,108,111])="4865777"(니블 깨짐, b%16 음수).
• 수정: 절단나눗셈 헬퍼로 _절단몫(b,16)·_절단나(b,16), _헥스글자는 0~15 직접 인덱스. 해시.한선의 중복 Base64 인코딩/디코딩도 동일 정정.
• 검증: 헥스([72,101,108,108,111])=48656c6c6f, [255,16,0]=ff1000, Base64(Man)=TWFu.

적용

• 라이브 바이너리 원자 swap(백업 .bak.top4), 윈도우 번들 exe 재빌드+libs(Base64·해시) 갱신+kps 재업로드(710KB), std 동기화.
• 라이브 검증 그린: 맵있나·포함하나·100/2=50.

3차: #7 float 수학함수 (완료)

• 문제: 수학 opcode가 cube_to_int로만 읽어 float 인자=garbage(반올림(3.7)=−6039454956, 루트(2.0)=−1, 사인(0.5)=−986, 거듭제곱(2.0,3.0)=1).
• 수정(crownyc.c): case 601~609(ROUND/FLOOR/CEIL/SQRT/ABS/SIN/COS/TAN/LOG) + case 87(POW)에 IS_FLOAT(a)?tfloat_to_double(&a):(double)cube_to_int(&a) 도입. POW는 float 인자 시 실수 pow→float 반환.
• 검증: 사인(0.5)=479, 코사인(0.5)=877, 반올림(3.7)=4, 거듭제곱(2.0,3.0)=8(float). 정수 입력 완전 불변(사인(1)=841, 루트(2000000)=1414, 거듭제곱(2,3)=8, 반올림(7)=7).
• 라이브 swap(.bak.top7) + 윈도우 번들 재업로드. 잔여 broken: 숫자변환("3.14")=3·JSON float파싱(문자열→실수 파싱은 별개).

4차: #5 함수 예외전파 (완료 — critical)

• 근본원인: CALL(247)이 rpush(pc)로 함수 리턴주소를 TRY 프레임과 같은 rstack에 쌓음 → 함수 안에서 던져(THROW)가 리턴주소를 TRY 프레임으로 오인 → 전파 실패(exit). 같은 스코프 try/throw는 정상.
• 수정(crownyc.c): 전용 trystack(handler/sp/rsp/callstack_depth/fsp/frame_ptr) 분리 — TRY(558)는 rstack 대신 trystack에 핸들러+언와인딩 상태 스냅샷, CATCH(559)는 trystack pop, THROW(560)는 가장 가까운 try로 호출 프레임까지 언와인딩(sp/rsp/callstack/fsp/frame_ptr 복원). mem_count는 복원 안 함(던진 힙객체 dangling 방지, 소량 누수 허용).
• 검증: 교차함수=99, 2단계중첩=99, 문자열예외="빈문자열", 함수내부 try+정상반환(10/0=-999), 중첩try(안쪽잡고 바깥계속), 루프중 함수throw 외부포착(합=3), 연속try 재사용(11,22), 재귀 팩(6)=720 회귀그린.
• 라이브 swap(.bak.top5) + 윈도우 번들 재업로드(710KB).

5차: 숫자변환 float (완료)

• 문제: 숫자변환(TOINT 486)이 strtol=정수전용 → 숫자변환("3.14")=3(소수점 절단).
• 수정(crownyc.c): 소수점 '.' 있으면 strtod→tfloat, 없으면 strtol→int(불변). TOSTR(488)은 이미 float 처리라 왕복 정상.
• 검증: 숫자변환("3.14")=3.14, 3.142=6.28, 정수("42")=42·음수("-7")=-7 불변. 라이브 .bak.numfloat + 번들.

6차: 적대적 재감사 + 발견 3결함 수정

울트라 6에이전트가 6개 수정을 적대적으로 공격(71+케이스). 4개 완전 견고(포함하나/맵있나/예외전파/float수학, 회귀0). 2개 partial — 약점은 수정 자체가 아닌 인접 VM 계층, 3결함 발견·전부 수정:

• 글자변환(n) U+10000↑ 미지원(이모지/4바이트→빈문자열, 내 Base64 디코드도 영향): crownyc.c case724에 4바이트 분기 추가. 글자변환(128512)=😀, Base64 이모지 왕복 OK.
• 범위초과 정수 리터럴 무경고 래핑(141214768241→곱셈경고 우회): hanseonc_high 숫자리터럴 emit에 컴파일 경고 추가(범위내 무경고, 오탐 없음).
• 해시.한선 Base64 char-vs-byte(안녕→SVU= 오답): Base64.한선처럼 _UTF8바이트들/_UTF8문자열로 재작성. 안녕=7JWI64WV.
• 라이브 swap(.bak.reaudit) + std/번들 동기화. 재감사 결론: 가이드형 배포 신뢰 가능(무조건 4 + 조건부였던 2도 결함 해소).

7차: #6 압축 라이브러리 포팅 (RPN→고수준)

명명 패턴 확인: X.한선=고수준 / X.rpn.한선=RPN(Base64가 그 예). 압축.한선이 RPN 오명명.

RPN 원본 → 압축.rpn.한선 보존, 고수준 압축.한선 신규 작성.

RLE_압축/RLE_해제: 마커(U+0001) 기반 비확장 RLE — 5자↑ 런만 "마커+문자+3자리", 마커 이스케이프, 999분할, 한글 글자단위, 왕복 무손실.

압축_비율(원본,압축): 절단나눗셈 백분율.

검증: 반복20→15(75%), 비반복 무확장(100%), 한글반복(86%), 긴런1500→10(0%), 마커충돌·빈문자열·import OK.

std/번들 동기화 + 학습(압축_RLE_마커기반_고수준). 잔여 #6=뷰828·하드웨어921줄(GUI/HDL 대공사), LZ77(향상).

8차: #6 뷰/하드웨어 포팅 + JSON float (완료)

JSON float: JSON.한선 _숫자파싱이 소수점/지수를 정확히 소비→숫자변환 위임. 숫자변환 수정(5차)으로 transitive 해결(추가코드 0). 검증: JSON파싱 pi=3.14159, neg=-2.5, [1.5]2=3.

뷰/하드웨어 포팅(병렬 Workflow 2 sonnet 에이전트): RPN 원본→X.rpn.한선 보존, 고수준 신규 작성.

하드웨어.한선(57함수): 신호/AND·OR·XOR·NAND·NOR게이트/가산기·N비트가산기/MUX·DEMUX/DFF/레지스터/메모리/시뮬/파형/삼진/시프트/비교기/디코더·인코더. 비트연산 빌트인+맵 상태기계.

뷰.한선(43함수): 창/상자/글씨/버튼/입력/카드/네비/제목/그리드/세로·가로 스택/자식추가/속성세터/조회/뷰그리기(/tmp/crowny_render 트리 직렬화)/히트테스트. 맵 트리+레이아웃 엔진.

독립검증이 에이전트 과보고 2건 적발·수정: ①DFF클럭이 클럭을 신호(맵)로 기대 → raw 0/1로 변경 ②메모리생성 3인자(이름,워드,주소비트) → 문서대로 1인자(크기). (비교기 배열반환·뷰둥글기 세터·시프트 3인자는 내 스모크 오류, 실제 정상.)

std/번들/학습. 교훈: Workflow 에이전트 결과는 독립 스모크 재검증 필수.

누적 완료: Top 1·2·3·4·5·6(압축+뷰+하드웨어)·7 + 헥스 + 숫자변환 + JSON float + 재감사3결함 — Top7 전부 착수완료

잔여

• #6 라이브러리 포팅(뷰828·하드웨어921·압축249줄 — 진짜 RPN 방언 .레이블/→저장/@점프 → hanseonc_high 고수준으로 포팅. correctness 아닌 feature 작업, 분량 大, 헌법 RPN정통 vs 고수준 결정 동반)
• XOR/HMAC(암호화.한선 RPN), 파일목록 배열반환(dirent 플랫폼 스텁, 체계("ls") 워크어라운드 존재), JSON.한선 float파싱

④ 맵 센티넬(없는키 INT_MIN) 정리+있나/없나 ⑤ 함수 예외전파+시도 무한루프 ⑥ 뷰/하드웨어/압축.한선 hanseonc_high 포팅 ⑦ float 수학함수 타입버그+파일목록 배열반환. 또한 헥스인코딩/XOR/HMAC 등 다른 암호 lib도 같은 절단나눗셈 정정 필요(Base64만 완료).

관련 파일

• crownyc.c (case 83 MUL 오버플로, case 750 STR_CONTAINS), hanseonc_high.c (포함하나 빌트인)
• libs/Base64.한선 + /Users/ef/Downloads/CrownyTVM/std/Base64.한선
• crowny-windows-package/crowny-bin/{crownyc.exe, hanseonc_high.exe, std/Base64.한선}