Intentionally unimplemented C API items (25 items)

[developer0hye]

Overview

As of PR #55, 245 out of 270 libjpeg-turbo API items are implemented (91%). The remaining 25 items are intentionally left unimplemented because they are C-specific internal APIs that Rust's language features already handle better.

This discussion documents why each is unnecessary.

---

Memory Management (6 items)

These exist because C has no automatic memory management. Rust's ownership system (Vec, Box, Drop) makes them redundant.

C API	Why unnecessary in Rust
jpeg_memory_mgr (pool allocator)	Rust std allocator handles all allocation/deallocation
alloc_small / alloc_large / alloc_sarray / alloc_barray	Vec::with_capacity() / Box::new()
request_virt_sarray / request_virt_barray / realize_virt_arrays / access_virt_sarray / access_virt_barray	Virtual array management — Rust uses Vec<Vec<T>>
free_pool / self_destruct	Drop trait auto-cleans up
max_memory_to_use / max_alloc_chunk	Already implemented as Decoder::set_max_memory()
tj3Alloc() / tj3Free()	Rust allocator

---

C Error Message System (9 items)

libjpeg uses a C-style error manager with function pointers, format strings, and message tables. Rust has Result<T, E>, Display trait, and DecodeWarning — a strictly better approach.

C API	Rust equivalent
output_message() callback	JpegError implements Display
format_message() callback	JpegError implements Display
reset_error_mgr()	Create a new Encoder/Decoder (zero cost)
trace_level control	ErrorHandler::trace() callback already implemented
num_warnings counter	Image.warnings / DecodeWarning list
msg_code / msg_parm	JpegError enum variants carry structured data
jpeg_message_table / addon_message_table	Not needed — error messages are in the Display impl
tj3GetErrorStr() / tj3GetErrorCode()	JpegError implements Display + pattern matching
jpeg_resync_to_restart()	Restart resync is handled internally in the decoder

---

C State Machine Reset Functions (4 items)

In C, you reuse a jpeg_compress_struct across multiple images and reset it. In Rust, you just create a new Encoder::new() — it's zero-cost and avoids stale state bugs.

C API	Why unnecessary
jpeg_default_qtables()	Just create a new Encoder — defaults are reset
jpeg_default_colorspace()	Same — new Encoder has default colorspace
jpeg_alloc_huff_table()	.huffman_dc_table() / .huffman_ac_table() builder methods
jpeg_suppress_tables()	Tables are written automatically based on what's needed

---

Truly Niche / Obsolete (4 items)

C API	Why unnecessary
CCIR601_sampling	1990s analog TV standard, not used in modern JPEG workflows
input_gamma	Gamma correction outside JPEG spec, not used in practice
in_color_space / jpeg_color_space independent control	.colorspace() builder already provides explicit override
q_scale_factor[NUM_QUANT_TBLS]	Already implemented as .quality_factor() (PR #31)

---

Could Implement But Very Low Value (2 items)

C API	Status
jpeg_write_icc_profile()	Standalone ICC write — already available via Encoder.icc_profile() during compression
jpeg_write_tables()	Write abbreviated tables-only JPEG — extremely rare use case

---

Summary

All 25 items fall into categories where Rust's language design provides a better alternative. Implementing them would add API surface without adding value, and could confuse users into using C patterns instead of idiomatic Rust.

If any of these become needed for FFI/C interop in the future, they can be added behind a ffi feature flag.