<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/93646>93646</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            [libc++] Feature Request - Code tweaks and build flags to produce smaller binaries when using <format> on embedded systems
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            libc++
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          BlamKiwi
      </td>
    </tr>
</table>

<pre>
    We currently use an internal format library that's a "lean" implementation of the standard for embedded devices. I've been trying to test libc++ `<format>` on embedded systems with very little RAM. There's some tweaks that can be made to make libc++ a bit leaner.

The C++ standard specifies that `float`, `double` and `long double` are explicitly listed types in `std::basic_format_arg`. This causes the compiler to pull in all float formatting code and associated lookup tables. This can cause binaries to bloat by >200KB even though it's never used. It is a common feature of embedded libc implementations to provide a compile option to disable float support in printf/scanf. It would be nice if libc++ provided a build flag to disable float types in `<format>`. 

`<charconv>` uses lookup tables or dedicated code paths to efficiently convert base 10, base 2, etc.  It would be good if optimized codepaths were guarded by `__OPTIMIZE_SIZE__` (or equivalent libc++ define) to prevent bringing in this code.

`__throw_invalid_option_format_error` and ` __throw_invalid_type_format_error` use `basic_string` and causes the contents of `string.cpp` to be pulled in. If exceptions are disabled, it would be nice if this message was simplified to a simple c string. 

`__format_escaped_char` and `__format_escaped_string` use a `basic_string` instead of just passing through the output iterator. Is there a reason this is the case? Directly passing in the iterator would produce smaller code in this instance. 
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJxsVctu2zoTfhp6M6gg05fECy9yqYGgKP4fPQUOcDbGiBxZ01KkSlJ2fZ7-YGglcdJsfKW-me8yQ0yJD55oq1b3avU4wzF3IW7vHfZf-MSzJtjz9m8CM8ZIPrszjIkAPbDPFD06aEPsMYPjJmI8Q-4wK32TAEFp7Qi90hq4Hxz15DNmDh5CC7kjSBm9xWgFA6hvyFqyYOnIhlIFT0rfHAkaIg85ntkfIAfIlEo1o_S90veg1rVaPFy6UIvPal1D8K9o6Zwy9QlOnDs4UjyD45wdwbe7rxV87yhSaTeFniCfCH-mwgEMemgIerQkZXv8SddlERrOIPwoVqp-VPXd5fV7R_AwHXohmAYy3DJN2Gpdty5glt71g3y1YWwcSfPorfzggj_A1a-RgH4Pjg2LCY5TJgv5PFAC9vJAylYt7tTirsHEZn8RZI_xoNa1EOUEBsdUWiAwoR_YURRqw-icgKBzUNqaPM2iuAmWSk-YUjCMUtaF8HMcIGPjxKcJ21_woWGPsVAN0BS45gxq8VnX9Zd7oKO42YXx0AFfkuLpSFFyZSt4ysCSHRP6PnhoCfMYSQLz4qiY8C5QpdYQw5Gl2WdyEIaSthzAcpJmJ3ppHIYQs3AeIvvcKr1LBn1b6p_C6KxY79kQcHvt-lTDiv0jOwutw8OfBa59eRfOCq7DcvnfdBhN8McpvsWkNxpDiGDJsinyF0sGzF2hTW3Lhi-zKSAUMzSYCOYlW-Wjlk-UTQVvCB5CsEJQdOr53wn6gnyiSHAYMQpbMXBd7_f_-__3p69P_3ze_yUve2lW6VsZ3l8jH9GRfzOallr2pPTmYo9Yn6GJ7A-SLJYcSHKCpeqdKPt97mI47dkf0bHdX5x8DjXFGOLVrMD746L_H4clm2pdX8YjZWnjGePNYPhMPieJXJkqOVeZYZCzkmgq80IW2Ffw1AL9NjRcQihDOgXBiuL8QZgK5Z5SwgPBCRMkibLsBivwePlOYGAq_T4v-xdiyeBAdi_puRLjj_9fqZbV_ZEG7FMmtML5x5gyDHItyLrtYhlUESaMeRgzcKaIOcQKnopgUSAjYQqTnTzpiInUYgePHMlINp8xi-30gjMpNMRgR0OQenSylkrGnxMi7aE3VMHMbhd2s9jgjLbzm_l6s7qpN8tZt90s2ho3pm7mrVnNl21zu9FNc7te17be2OV8xltd62W90pt6uZgvltXa3tLmdrVq12iaeU1qWVOP7Crnjn0V4mHGKY203SzWy_XMYUMulVtS69eIK63l1oxbeehTMx6SWtaynNMrTObsyv169djqEXbTavtGv0a50j7Bg3CeriAx83XDPO-3NxK97NlTRx7GIu71svnoGpyN0W27nIckd4XeKb07cO7GpjKhV3onTU9vn4YYfpDJSu-KEEnp3UWL41b_FwAA__-1882p">