--- id: c-errors title: "C Errors" category: "Programming_Language" status: "draft" verification_status: "conceptual" canonical_id: "" aliases: ["compile-time vs runtime errors", "use-after-free", "C μ—λŸ¬"] duplicate_of: "" source_trust_level: "B" confidence_score: 0.86 created_at: 2026-07-04 updated_at: 2026-07-04 review_reason: "" merge_history: [] tags: ["c", "programming-language", "w3schools", "errors"] raw_sources: ["https://www.w3schools.com/c/c_errors.php"] applied_in: [] github_commit: "" --- # [[C Errors]] ## 🎯 ν•œ 쀄 톡찰 (One-line insight) The three runtime error examples (divide-by-zero, out-of-bounds array access, use-after-free) all share a common trait the source doesn't state explicitly but demonstrates through selection: NONE of them are caught by the compiler β€” all three compile cleanly and only misbehave when actually EXECUTED β€” meaning C's compile-time checking is fundamentally limited to syntax/type issues, while logic and memory-safety issues are entirely the programmer's responsibility to prevent at runtime. [S1] ## 🧠 핡심 κ°œλ… (Core concepts) - **Compile-time errors** β€” prevent the program from compiling at all; e.g. missing semicolon, undeclared variable, mismatched types (assigning a string literal to an `int`). [S1] - **Runtime errors** β€” the program compiles successfully but crashes or misbehaves when RUN; e.g. division by zero, out-of-bounds array access, using memory after `free()`. [S1] - **Use-after-free** β€” reading `*ptr` after `free(ptr)` is explicitly labeled "undefined behavior," not a guaranteed crash β€” meaning it might appear to work sometimes, making it a particularly dangerous class of bug. [S1] - **Good habits** β€” always initialize variables, use meaningful names, keep indentation clean, keep functions short/focused, verify loop/condition behavior, and read error messages carefully (they often pinpoint the exact problem). [S1] ## πŸ“– μ„ΈλΆ€ λ‚΄μš© (Details) - Missing semicolon (compile-time): `int x = 5 printf("%d", x);` β†’ `error: expected ',' or ';' before 'printf'`. [S1] - Type mismatch (compile-time): `int x = "Hello";` β†’ `error: initialization makes integer from pointer without a cast`. [S1] - Use-after-free (runtime, undefined behavior): `int* ptr = malloc(sizeof(int)); *ptr = 10; free(ptr); printf("%d\n", *ptr); // accessing freed memory`. [S1] ## βš–οΈ λͺ¨μˆœ 및 μ—…λ°μ΄νŠΈ (Contradictions & updates) - **ν•΄μ œλœ λ©”λͺ¨λ¦¬ 접근은 "λ―Έμ •μ˜ λ™μž‘"**: free() 이후 포인터λ₯Ό μ½λŠ” 것이 항상 ν¬λž˜μ‹œλ‘œ μ΄μ–΄μ§€λŠ” 것이 μ•„λ‹ˆλΌ "undefined behavior"둜 λͺ…μ‹œλ˜μ–΄, μš°μ—°νžˆ 정상 λ™μž‘ν•˜λŠ” κ²ƒμ²˜λŸΌ 보일 μˆ˜λ„ μžˆμ–΄ 더 μœ„ν—˜ν•˜λ‹€λŠ” 점이 확인됨. [S1] ## πŸ› οΈ 적용 사둀 (Applied in summary) ν˜„μž¬ 발견된 μ‹€μ œ 적용 사둀가 μ—†μŠ΅λ‹ˆλ‹€ β€” 컴파일 νƒ€μž„ μ—λŸ¬ 3μ’…κ³Ό λŸ°νƒ€μž„ μ—λŸ¬ 3쒅을 λ‚˜λž€νžˆ λŒ€λΉ„μ‹œν‚¨ 것이 두 μ—λŸ¬ λ²”μ£Όμ˜ 근본적 차이λ₯Ό μ΄ν•΄ν•˜λŠ” μ‹€μ „ ν•™μŠ΅ 자료둜 ν™œμš©λœλ‹€. [S1] ## πŸ’» μ½”λ“œ νŒ¨ν„΄ (Code patterns) Using memory after it's been freed β€” compiles fine, but is undefined behavior at runtime (C): ```c int* ptr = malloc(sizeof(int)); *ptr = 10; free(ptr); printf("%d\n", *ptr); // Undefined behavior - accessing memory that was freed ``` ## βœ… 검증 μƒνƒœ 및 신뒰도 - **μƒνƒœ:** draft - **검증 단계:** conceptual - **좜처 신뒰도:** B (W3Schools β€” widely used educational reference, not a primary standards body) - **μ‹ λ’° 점수:** 0.86 - **쀑볡 검사 κ²°κ³Ό:** μ‹ κ·œ 생성 (New discovery) ## πŸ”— 지식 κ·Έλž˜ν”„ (Knowledge Graph) - **μƒμœ„/루트:** [[C Tutorial]] - **κ΄€λ ¨ κ°œλ…:** [[C Date Time]], [[C Memory Deallocate]], [[C Error Handling]] - **μ°Έμ‘° λ§₯락:** μ—λŸ¬ μ„Ήμ…˜ 첫 챕터 β€” μ—λŸ¬ 처리(Error Handling) μ±•ν„°λ‘œ 이어짐. ## πŸ“š 좜처 (Sources) - [S1] W3Schools β€” C Errors β€” https://www.w3schools.com/c/c_errors.php ## πŸ“ λ³€κ²½ 이λ ₯ (Change history) - 2026-07-04: Initial draft synthesized from the W3Schools "C Errors" page (Astra wiki-curation, P-Reinforce v3.1 format).