crates/common/src/format.rs (1)

525-536: ⚠️ Potential issue | 🟠 Major

apply_locale_formatting still corrupts exponent notation for numbers without decimal points.

The previous review flagged this issue and a fix was suggested, but the current code doesn't include that fix. When format_general produces output like "1e+06" (no decimal point), splitn(2, '.') yields the entire string as int_part, and insert_locale_grouping will corrupt it by inserting separators into non-digit characters.

💡 Suggested fix: handle exponent notation

 fn apply_locale_formatting(magnitude_str: String, locale: &LocaleInfo) -> String {
+    // Separate exponent part before processing
+    let (mantissa, exponent) = match magnitude_str.find(|c| c == 'e' || c == 'E') {
+        Some(pos) => (&magnitude_str[..pos], Some(&magnitude_str[pos..])),
+        None => (magnitude_str.as_str(), None),
+    };
+
-    let mut parts = magnitude_str.splitn(2, '.');
+    let mut parts = mantissa.splitn(2, '.');
     let int_part = parts.next().unwrap();
     let grouped = Self::insert_locale_grouping(int_part, locale);

-    if let Some(frac_part) = parts.next() {
+    let result = if let Some(frac_part) = parts.next() {
         format!("{grouped}{}{frac_part}", locale.decimal_point)
     } else {
         grouped
+    };
+
+    match exponent {
+        Some(exp) => format!("{result}{exp}"),
+        None => result,
     }
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/common/src/format.rs` around lines 525 - 536, apply_locale_formatting
currently corrupts exponent notation like "1e+06" because it applies
insert_locale_grouping to the whole int_part; fix by detecting an exponent ('e'
or 'E') in the original magnitude_str (or int_part) and split off the exponent
suffix before grouping, then only call insert_locale_grouping on the mantissa
integer portion (preserving any leading sign), finally reassemble as
"{grouped_mantissa}{optional_decimal_point}{frac_part}{exponent_suffix}" so
exponents remain untouched; update apply_locale_formatting to locate 'e'/'E',
separate exponent, preserve sign, call insert_locale_grouping on the numeric
digits, and then concatenate the exponent back.

crates/common/src/format.rs (2)

564-564: ⚠️ Potential issue | 🟡 Minor

Locale width/alignment uses byte length instead of character count.

At Line 564, Line 604, and Line 656, locale-formatted strings are wrapped as AsciiStr. AsciiStr::char_len() (Line 1040) uses byte length, so width padding is wrong for multibyte separators (e.g., NBSP thousands separator).

💡 Proposed direction

- self.format_sign_and_align(&AsciiStr::new(&magnitude_str), sign_str, FormatAlign::Right)
+ self.format_sign_and_align(&UnicodeStr::new(&magnitude_str), sign_str, FormatAlign::Right)

// Add alongside AsciiStr
struct UnicodeStr<'a> {
    inner: &'a str,
}

impl<'a> UnicodeStr<'a> {
    const fn new(inner: &'a str) -> Self {
        Self { inner }
    }
}

impl CharLen for UnicodeStr<'_> {
    fn char_len(&self) -> usize {
        self.inner.chars().count()
    }
}

impl Deref for UnicodeStr<'_> {
    type Target = str;
    fn deref(&self) -> &Self::Target {
        self.inner
    }
}

#!/bin/bash
# Verify current locale-format callsites and CharLen behavior.
rg -n "AsciiStr::new\\(&magnitude_str\\)" crates/common/src/format.rs
sed -n '1038,1042p' crates/common/src/format.rs

Also applies to: 604-604, 656-656

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/common/src/format.rs` at line 564, Locale-formatted strings are being
wrapped with AsciiStr (via AsciiStr::new(&magnitude_str)) but
AsciiStr::char_len() returns byte length, breaking width/alignment for multibyte
separators; introduce a UnicodeStr<'a> wrapper (with new(inner: &'a str)),
implement CharLen for it using self.inner.chars().count(), and Deref<Target=str>
so it behaves like &str, then replace the locale-related AsciiStr::new(...)
callsites (the calls into format_sign_and_align / format_* that pass
&AsciiStr::new(&magnitude_str)) with &UnicodeStr::new(&magnitude_str) and add
any necessary use/imports.

---

525-536: ⚠️ Potential issue | 🟠 Major

Group only mantissa digits before locale insertion.

At Line 527, the whole pre-. chunk is grouped. Scientific notation without a decimal point (e.g., 1e+06) gets corrupted by separator insertion. This also affects callers at Line 591 and Line 650.

💡 Proposed fix

 fn apply_locale_formatting(magnitude_str: String, locale: &LocaleInfo) -> String {
-    let mut parts = magnitude_str.splitn(2, '.');
-    let int_part = parts.next().unwrap();
-    let grouped = Self::insert_locale_grouping(int_part, locale);
-
-    if let Some(frac_part) = parts.next() {
-        format!("{grouped}{}{frac_part}", locale.decimal_point)
-    } else {
-        grouped
-    }
+    let exp_pos = magnitude_str.find(|c| c == 'e' || c == 'E');
+    let (mantissa, exponent) = exp_pos
+        .map(|i| (&magnitude_str[..i], Some(&magnitude_str[i..])))
+        .unwrap_or((magnitude_str.as_str(), None));
+
+    let (int_part, frac_part) = mantissa
+        .split_once('.')
+        .map_or((mantissa, None), |(i, f)| (i, Some(f)));
+
+    let grouped = if int_part.chars().all(|c| c.is_ascii_digit()) {
+        Self::insert_locale_grouping(int_part, locale)
+    } else {
+        int_part.to_owned()
+    };
+
+    let mut out = if let Some(frac_part) = frac_part {
+        format!("{grouped}{}{frac_part}", locale.decimal_point)
+    } else {
+        grouped
+    };
+    if let Some(exponent) = exponent {
+        out.push_str(exponent);
+    }
+    out
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/common/src/format.rs` around lines 525 - 536, The current
apply_locale_formatting function applies grouping to the entire pre-decimal
chunk, corrupting scientific exponents like "1e+06"; update
apply_locale_formatting to detect and preserve any exponent suffix (look for 'e'
or 'E' plus the rest) by splitting magnitude_str into mantissa, optional
fractional part, and optional exponent, apply Self::insert_locale_grouping only
to the mantissa's integer digits, then recombine mantissa (with
locale.decimal_point and frac if present) and append the untouched exponent;
ensure magnitude_str, insert_locale_grouping, and locale.decimal_point are used
accordingly so exponents remain unmodified (this change will also fix the
callers that rely on apply_locale_formatting).

crates/vm/src/format.rs (1)

49-67: ⚠️ Potential issue | 🟠 Major

Preserve CHAR_MAX semantics in parse_grouping.

At Line 50 and Line 64, the implementation always appends 0 after parsing non-empty grouping data. If the C sequence ends with CHAR_MAX, this incorrectly changes behavior from “stop grouping” to “repeat last group forever.”

💡 Proposed fix

 /// Parse C `lconv.grouping` into a `Vec<u8>`.
-/// Reads bytes until 0 or CHAR_MAX, then appends 0 (meaning "repeat last group").
+/// Reads bytes until 0 or CHAR_MAX.
+/// - 0 means "repeat last group size"
+/// - CHAR_MAX means "stop grouping"
 #[cfg(unix)]
 unsafe fn parse_grouping(grouping: *const libc::c_char) -> Vec<u8> {
     let mut result = Vec::new();
     if grouping.is_null() {
         return result;
     }
-    unsafe {
-        let mut ptr = grouping;
-        while ![0, libc::c_char::MAX].contains(&*ptr) {
-            result.push(*ptr as u8);
-            ptr = ptr.add(1);
-        }
+    let mut ptr = grouping;
+    let mut repeat_last = false;
+    loop {
+        let v = *ptr;
+        if v == 0 {
+            repeat_last = true;
+            break;
+        }
+        if v == libc::c_char::MAX {
+            break;
+        }
+        result.push(v as u8);
+        ptr = ptr.add(1);
     }
-    if !result.is_empty() {
+    if repeat_last && !result.is_empty() {
         result.push(0);
     }
     result
 }

In POSIX/C `localeconv()`, for `lconv.grouping`, what are the semantics of terminators `0` and `CHAR_MAX`, and should `CHAR_MAX` stop further grouping rather than repeat the previous size?

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/vm/src/format.rs` around lines 49 - 67, The parse_grouping function
currently always appends a 0 terminator after collecting bytes, which
incorrectly changes semantics when the original C sequence ended with CHAR_MAX
(meaning "stop grouping"); modify parse_grouping to detect which terminator
stopped the loop (0 vs CHAR_MAX) by inspecting the terminating byte at the stop
condition and only append a 0 to result if the terminator was 0; reference the
unsafe fn parse_grouping(grouping: *const libc::c_char), the loop that reads
*ptr, and libc::c_char::MAX/0 to implement this conditional behavior.

crates/common/src/format.rs (3)

525-536: ⚠️ Potential issue | 🟠 Major

Don’t run grouping across exponent text in apply_locale_formatting.

At Line 527-Line 533, grouping is applied to everything before .; exponent forms like 1e+06 can be altered incorrectly.

Suggested fix

 fn apply_locale_formatting(magnitude_str: String, locale: &LocaleInfo) -> String {
-    let mut parts = magnitude_str.splitn(2, '.');
-    let int_part = parts.next().unwrap();
-    let grouped = Self::insert_locale_grouping(int_part, locale);
-
-    if let Some(frac_part) = parts.next() {
-        format!("{grouped}{}{frac_part}", locale.decimal_point)
-    } else {
-        grouped
-    }
+    let exp_pos = magnitude_str.find(|c| c == 'e' || c == 'E');
+    let (mantissa, exponent) = if let Some(pos) = exp_pos {
+        (&magnitude_str[..pos], Some(&magnitude_str[pos..]))
+    } else {
+        (magnitude_str.as_str(), None)
+    };
+    let (int_part, frac_part) = mantissa
+        .split_once('.')
+        .map_or((mantissa, None), |(i, f)| (i, Some(f)));
+
+    let grouped = if int_part.chars().all(|c| c.is_ascii_digit()) {
+        Self::insert_locale_grouping(int_part, locale)
+    } else {
+        int_part.to_owned()
+    };
+
+    let mut out = if let Some(frac_part) = frac_part {
+        format!("{grouped}{}{frac_part}", locale.decimal_point)
+    } else {
+        grouped
+    };
+    if let Some(exponent) = exponent {
+        out.push_str(exponent);
+    }
+    out
 }

For Python format specifier 'n', should locale grouping/decimal substitution affect exponent parts (e.g., '1e+06') or only the mantissa?

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/common/src/format.rs` around lines 525 - 536, The current
apply_locale_formatting applies grouping to the whole pre-decimal text and can
corrupt exponent text like "1e+06"; update apply_locale_formatting to first
split magnitude_str into mantissa and exponent by searching for 'e' or 'E'
(preserve the original exponent sign and digits), then perform the existing
splitn('.') and call insert_locale_grouping only on the mantissa's integer part
and replace the decimal point only in the mantissa, finally reattach the
exponent unchanged; reference apply_locale_formatting and insert_locale_grouping
so the mantissa/exponent split and reassembly are done before grouping/decimal
replacement.

---

607-657: ⚠️ Potential issue | 🟠 Major

Locale complex path should enforce the same invalid-flag checks as format_complex.

format_complex_locale currently skips the =-alignment and zero-padding validation present in format_complex, so invalid specs can slip through.

Suggested fix

 pub fn format_complex_locale(
     &self,
     num: &Complex64,
     locale: &LocaleInfo,
 ) -> Result<String, FormatSpecError> {
+    if let Some(FormatAlign::AfterSign) = &self.align {
+        return Err(FormatSpecError::AlignmentFlag);
+    }
+    if matches!(self.fill.unwrap_or(' '.into()).to_char(), Some('0')) {
+        return Err(FormatSpecError::ZeroPadding);
+    }
+
     // Reuse format_complex_re_im with 'g' type to get the base formatted parts,
     // then apply locale grouping. This matches CPython's format_complex_internal:
     // 'n' → 'g', add_parens=0, skip_re=0.

#!/bin/bash
# Compare validation behavior in locale/non-locale complex formatting
rg -n "fn format_complex_locale|fn format_complex|AlignmentFlag|ZeroPadding" crates/common/src/format.rs -A20 -B10

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/common/src/format.rs` around lines 607 - 657, format_complex_locale
skips the same validation performed by format_complex for illegal '=' alignment
and zero-padding flags, allowing invalid format specs; update
format_complex_locale to run the identical validation path as format_complex
(either call the same validation helper or inline the same checks) before
proceeding—specifically validate AlignmentFlag '=' and zero-padding combinations
on the FormatSpec used (see FormatSpec, format_complex_re_im, format_complex,
format_sign_and_align) and return the same FormatSpecError when flags are
invalid so locale handling cannot bypass the checks.

---

564-565: ⚠️ Potential issue | 🟡 Minor

Locale width alignment is byte-counted, so multibyte separators can mispad.

These locale paths pass AsciiStr, whose char_len() is byte length; locale separators can be multibyte UTF-8, so width/fill becomes inaccurate.

In Rust, does str::len() return byte length or Unicode scalar count, and what is the recommended way to compute character count for width-sensitive formatting?

Also applies to: 604-605, 656-657

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/common/src/format.rs` around lines 564 - 565, The code calls
format_sign_and_align(&AsciiStr::new(&magnitude_str), sign_str,
FormatAlign::Right) and relies on AsciiStr/char_len() (which yields byte length)
for width calculations, causing mispadding when locale separators are multibyte
UTF‑8; change the logic to use a Unicode-aware display width (e.g., use
unicode_width::UnicodeWidthStr::width on &str or compute grapheme clusters if
needed) instead of byte length, update the call sites that construct AsciiStr
(including other occurrences around format_sign_and_align) to pass a &str or a
precomputed display width, and modify format_sign_and_align to accept and use
the unicode-width result (or accept a width parameter) so padding/fill is based
on displayed character width rather than bytes.

crates/vm/src/format.rs (1)

49-68: ⚠️ Potential issue | 🟠 Major

parse_grouping currently conflates 0 and CHAR_MAX terminators.

At Line 64-Line 66, 0 is appended for any non-empty sequence, which incorrectly turns CHAR_MAX (“stop grouping”) into “repeat previous group”.

Suggested fix

 unsafe fn parse_grouping(grouping: *const libc::c_char) -> Vec<u8> {
     let mut result = Vec::new();
     if grouping.is_null() {
         return result;
     }
-    unsafe {
-        let mut ptr = grouping;
-        while ![0, libc::c_char::MAX].contains(&*ptr) {
-            result.push(*ptr as u8);
-            ptr = ptr.add(1);
-        }
-    }
-    if !result.is_empty() {
+    let mut ptr = grouping;
+    let mut repeat_last = false;
+    loop {
+        let v = unsafe { *ptr };
+        if v == 0 {
+            repeat_last = true;
+            break;
+        }
+        if v == libc::c_char::MAX {
+            break;
+        }
+        result.push(v as u8);
+        ptr = unsafe { ptr.add(1) };
+    }
+    if repeat_last && !result.is_empty() {
         result.push(0);
     }
     result
 }

In POSIX/C localeconv().grouping semantics, what is the difference between a 0 byte and CHAR_MAX terminator, and should they be handled differently when parsing grouping rules?

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/vm/src/format.rs` around lines 49 - 68, The parse_grouping function
conflates CHAR_MAX and NUL terminators by always appending a 0 byte for
non-empty results; change it so the code inspects the terminator byte at the
stopping pointer and only push a trailing 0 (the "repeat last group" marker)
when the terminator was NUL (0), not when it was libc::c_char::MAX; update
unsafe fn parse_grouping to stop on either terminator as before but after the
loop check *ptr (or the last read byte) and conditionally push 0 only if that
terminator == 0, leaving CHAR_MAX-terminated sequences without the appended 0.

crates/common/src/format.rs (3)

564-564: ⚠️ Potential issue | 🟡 Minor

Width/padding can be wrong for multibyte locale separators.

Lines 564, 604, and 653 pass locale-formatted strings through AsciiStr; char_len() is byte-based, so width calculation drifts when thousands_sep / decimal_point are multibyte UTF-8.

💡 Proposed fix

- self.format_sign_and_align(&AsciiStr::new(&magnitude_str), sign_str, FormatAlign::Right)
+ self.format_sign_and_align(magnitude_str.as_str(), sign_str, FormatAlign::Right)

And update format_sign_and_align to compute Unicode character count for &str input:

- fn format_sign_and_align<T>(&self, magnitude_str: &T, sign_str: &str, default_align: FormatAlign) -> Result<String, FormatSpecError>
- where
-     T: CharLen + Deref<Target = str>,
+ fn format_sign_and_align(
+     &self,
+     magnitude_str: &str,
+     sign_str: &str,
+     default_align: FormatAlign,
+ ) -> Result<String, FormatSpecError>
 {
     let align = self.align.unwrap_or(default_align);
-    let num_chars = magnitude_str.char_len();
+    let num_chars = magnitude_str.chars().count();

Also applies to: 604-604, 653-653

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/common/src/format.rs` at line 564, The code incorrectly wraps
locale-formatted strings with AsciiStr and uses byte-based char_len(), causing
wrong width/padding when thousands_sep/decimal_point are multibyte; update the
call sites (the three places passing AsciiStr instances) to pass plain &str (the
formatted magnitude strings and any sign_str inputs) into format_sign_and_align,
and change format_sign_and_align to accept &str instead of AsciiStr and compute
widths using Unicode character count (e.g., s.chars().count()) when calculating
padding/alignment so multibyte separators are measured correctly.

---

525-536: ⚠️ Potential issue | 🟠 Major

apply_locale_formatting can group non-digit mantissas (e.g., scientific notation).

Line 529 groups the full pre-. chunk. Values like 1e+06, inf, or nan can be transformed incorrectly (for example, 1e,+06).

💡 Proposed fix

 fn apply_locale_formatting(magnitude_str: String, locale: &LocaleInfo) -> String {
-    let mut parts = magnitude_str.splitn(2, '.');
-    let int_part = parts.next().unwrap();
-    let grouped = Self::insert_locale_grouping(int_part, locale);
-
-    if let Some(frac_part) = parts.next() {
-        format!("{grouped}{}{frac_part}", locale.decimal_point)
-    } else {
-        grouped
-    }
+    let exp_pos = magnitude_str.find(|c| c == 'e' || c == 'E');
+    let (mantissa, exponent) = if let Some(pos) = exp_pos {
+        (&magnitude_str[..pos], Some(&magnitude_str[pos..]))
+    } else {
+        (magnitude_str.as_str(), None)
+    };
+    let (int_part, frac_part) = mantissa
+        .split_once('.')
+        .map_or((mantissa, None), |(i, f)| (i, Some(f)));
+
+    let grouped = if int_part.chars().all(|c| c.is_ascii_digit()) {
+        Self::insert_locale_grouping(int_part, locale)
+    } else {
+        int_part.to_owned()
+    };
+
+    let mut out = if let Some(frac_part) = frac_part {
+        format!("{grouped}{}{frac_part}", locale.decimal_point)
+    } else {
+        grouped
+    };
+    if let Some(exponent) = exponent {
+        out.push_str(exponent);
+    }
+    out
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/common/src/format.rs` around lines 525 - 536, apply_locale_formatting
currently passes the entire pre-decimal chunk to insert_locale_grouping which
corrupts non-digit mantissas like "1e+06", "inf", or "nan"; fix by isolating an
optional leading sign and the contiguous digit sequence in int_part, call
insert_locale_grouping only on that digit sequence (or on "0" when no digits),
then reassemble sign + grouped_digits + trailing_suffix (the remaining non-digit
chars) before attaching the fractional part and decimal_point; update
apply_locale_formatting to parse int_part into (sign, digit_run, suffix) and use
insert_locale_grouping on digit_run so symbols like apply_locale_formatting,
insert_locale_grouping, magnitude_str, and LocaleInfo are the only points
changed.

---

650-654: ⚠️ Potential issue | 🟠 Major

Locale complex formatting skips complex-specific flag validation.

Lines 653-654 directly format output, but this path does not enforce the same AlignmentFlag / ZeroPadding checks used in format_complex (Lines 861-867). Invalid specs can pass silently here.

💡 Proposed fix

         // No parentheses for 'n' format (CPython: add_parens=0)
         let magnitude_str = format!("{grouped_re}{grouped_im}");
-
-        self.format_sign_and_align(&AsciiStr::new(&magnitude_str), "", FormatAlign::Right)
+        if let Some(FormatAlign::AfterSign) = &self.align {
+            return Err(FormatSpecError::AlignmentFlag);
+        }
+        match &self.fill.unwrap_or(' '.into()).to_char() {
+            Some('0') => Err(FormatSpecError::ZeroPadding),
+            _ => self.format_sign_and_align(&AsciiStr::new(&magnitude_str), "", FormatAlign::Right),
+        }
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/common/src/format.rs` around lines 650 - 654, The locale-specific
branch builds magnitude_str and calls self.format_sign_and_align without
validating complex-number-specific flags, allowing invalid
AlignmentFlag/ZeroPadding specs to pass; add the same validation used in
format_complex (the checks around AlignmentFlag and ZeroPadding in the
format_complex path) before formatting here or refactor to call the shared
validator, then only proceed to call
self.format_sign_and_align(&AsciiStr::new(&magnitude_str), "",
FormatAlign::Right) if the validation passes so invalid specs are rejected
consistently.

crates/vm/src/format.rs (1)

49-67: ⚠️ Potential issue | 🟠 Major

parse_grouping currently treats CHAR_MAX like repeat-last grouping.

At Lines 64-66, a trailing 0 is appended for any non-empty sequence. That makes CHAR_MAX-terminated patterns behave as “repeat last group forever” instead of “stop further grouping”.

💡 Proposed fix

 /// Parse C `lconv.grouping` into a `Vec<u8>`.
-/// Reads bytes until 0 or CHAR_MAX, then appends 0 (meaning "repeat last group").
+/// Reads bytes until 0 or CHAR_MAX.
+/// - 0 means "repeat last group"
+/// - CHAR_MAX means "stop further grouping"
 #[cfg(unix)]
 unsafe fn parse_grouping(grouping: *const libc::c_char) -> Vec<u8> {
     let mut result = Vec::new();
     if grouping.is_null() {
         return result;
     }
-    unsafe {
-        let mut ptr = grouping;
-        while ![0, libc::c_char::MAX].contains(&*ptr) {
-            result.push(*ptr as u8);
-            ptr = ptr.add(1);
-        }
-    }
-    if !result.is_empty() {
+    let mut ptr = grouping;
+    let mut repeat_last = false;
+    loop {
+        let value = unsafe { *ptr };
+        if value == 0 {
+            repeat_last = true;
+            break;
+        }
+        if value == libc::c_char::MAX {
+            break;
+        }
+        result.push(value as u8);
+        ptr = unsafe { ptr.add(1) };
+    }
+    if repeat_last && !result.is_empty() {
         result.push(0);
     }
     result
 }

In POSIX/C localeconv() semantics for lconv.grouping, what do terminators 0 and CHAR_MAX mean, and should they be handled differently when converting grouping rules?

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/vm/src/format.rs` around lines 49 - 67, parse_grouping currently
always appends a trailing 0 (meaning "repeat last group") even when the original
C terminator was CHAR_MAX (meaning "stop grouping"); modify parse_grouping to
inspect the terminator byte after the loop and only append 0 if the terminator
was actually 0, and do not append anything when the terminator was
libc::c_char::MAX. Locate the unsafe fn parse_grouping(grouping: *const
libc::c_char) -> Vec<u8>, keep the loop that advances ptr while *ptr is not 0 or
libc::c_char::MAX, then check the byte at ptr: if *ptr == 0 { if
!result.is_empty() { result.push(0); } } else /* CHAR_MAX */ { /* leave result
as-is */ } and return result.