java-topology/defects/emacs/patch/CLEAN.md
russell@unturf.com 178d9c03db scan: HandBrake + Emacs CWE-407 — both CLEAN
HandBrake: libhb uses array-backed lists bounded by media metadata
sizes (tracks, subtitles, chapters, presets). No user-controlled
quadratic growth path found.

Emacs: C core uses Fmemq/Fmember on small bounded lists (property
lists, error conditions, flags). Larger lists (features ~1000,
charsets ~200) only scanned in non-hot-path code. Elisp delete-dups
already has hash optimization for >100 elements.
2026-03-30 11:45:36 -04:00

2.5 KiB

Emacs — CWE-407 Scan Result: CLEAN

Date: 2026-03-30 Target: GNU Emacs (C + Elisp) Source: https://github.com/emacs-mirror/emacs (depth=1)

Scan Summary

Scanned src/ (C core: eval.c, fns.c, keymap.c, buffer.c, charset.c, coding.c, font.c, fontset.c, textprop.c, intervals.c, keyboard.c, xdisp.c, window.c, undo.c, treesit.c, comp.c, process.c, minibuf.c, xfaces.c, gfilenotify.c, kqueue.c, callint.c) and lisp/ (subr.el, simple.el, bytecomp.el).

Areas Examined

  • Undo list (undo.c): Pure prepend + size-based truncation. No membership checks in hot path. Clean.
  • Buffer list (buffer.c): Frassq + Fmemq + Fdelq on Vbuffer_alist — each O(N) but individual calls, not inside loops. Clean.
  • Keymap lookup (keymap.c): Fmember(sequence, found) in where-is-internal is O(N²) but N = bindings per command (typically <10), and it's an interactive inspection command, not a hot path.
  • let/let* (eval.c): Fmemq(var, Vinternal_interpreter_environment) scans for bare symbols only (from defvar), not full environment. Bare symbol count is typically 0-5 per scope.
  • require (fns.c): Fmemq(feature, Vfeatures) is O(F) per call where F = loaded features (~500-1000). Called at load-time only, not in tight loops.
  • Charset priority (charset.c): Fmemq inside loop is O(N²) with N~200 charsets, but called only on explicit set-charset-priority (rare user action).
  • Text properties (textprop.c, intervals.c): TMEM macro uses Fmemq on property lists (front-sticky, rear-nonsticky) — always <5 elements. Clean.
  • Font features (font.c): Fmemq(feature, table) with features ~1-5 and table per-font. Clean.
  • delete-dups (subr.el): Already has hash-table optimization for lists >100 elements. Shows awareness of the pattern.
  • Byte compiler (bytecomp.el): member on bytecomp--code-strings reset per top-level form, typically 0-5 entries. Clean.
  • Window traversal (buffer.c:2689): Fmemq(w, ws) cycle detection is O(W²) with W = window count (<20). Clean.

Conclusion

Emacs's C core uses Fmemq/Fmember/Fassq extensively but on small, bounded lists (property lists, error conditions, flag lists, media features). The few potentially larger lists (Vfeatures ~500-1000, Vcharset_ordered_list ~200) are scanned in non-hot-path code (load-time, user commands). The Elisp layer already applies hash optimization where lists can grow large (delete-dups). No CWE-407 defect of actionable severity found.