[libc++] ABI break: std::__format::__formatted_size_buffer/__format_to_n_buffer

[zibi2]

Compiling std/utilities/format/format.functions/locale-specific_form.pass.cpp with -std=c++26 -Xclang -fdump-record-layouts-canonical -fsyntax-only against LLVM 19 and LLVM 21 will result with the following difference:

          0 | class std::__format::__formatted_size_buffer<char>
-         0 |   class std::__format::__internal_storage<char> __storage_
-         0 |     char[256] __buffer_
-       256 |   class std::__format::__output_buffer<char> __output_
-       256 |     char * __ptr_
-       264 |     unsigned long __capacity_
-       272 |     unsigned long __size_
-       280 |     void (*)(char *, unsigned long, void *) __flush_
-       288 |     void * __obj_
-       296 |   unsigned long __size_
-           | [sizeof=304, dsize=304, align=8,
-           |  nvsize=304, nvalign=8]
+         0 |   class std::__format::__output_buffer<char> (base)
+         0 |     char * __ptr_
+         8 |     unsigned long __capacity_
+        16 |     unsigned long __size_
+        24 |     void (*)(class std::__format::__output_buffer<char> &, unsigned long) __prepare_write_
+        32 |     class std::__format::__max_output_size * __max_output_size_
+        40 |   class std::__format::__max_output_size __max_output_size_
+        40 |     unsigned long __max_size_
+        48 |     unsigned long __code_units_written_
+           | [sizeof=56, dsize=56, align=8,
+           |  nvsize=56, nvalign=8]

The difference is coming from __storage_ member which takes 256 bytes in space. I believe this was changed in PR 157592.

Similar diffs are also observed in various instantiations of std::__format::__formatted_size_buffer.

[philnik777]

What's the problem here? __output_buffer is a fully internal type.

[ldionne]

@zibi2 Out of curiosity, are you developing a tool to try catching ABI changes between versions? We should probably chat about how to integrate this upstream, it would probably provide a lot of value if we can do it in a way that we minimize noise.

[zibi2]

What's the problem here? __output_buffer is a fully internal type.

I see __output_buffer being defined in public header __format/buffer.h, if that would be defined in src directory that would be a different story but it is exposed to the users. However, I don't see issue with __output_buffer but with __formatted_size_buffer which has changed it's size. The question is whether a code involving ``__formatted_size_buffer` compiled with LLVM19/20 can execute safely using LLVM 21 libc++.

[ldionne]

Not all types present in our headers are exposed to users. Many such types are used in a local fashion (e.g. a temporary variable or similar), and they are used from functions who are ABI-tagged with the version of the library. Therefore we are free to change these types to our leisure without risk of an ABI break or an ODR violation.

[ldionne]

I'm sure there is a way to systematically determine whether a type is ABI-relevant, but I don't know what it is. It's definitely more subtle than just the location where it is defined, though. Generally we just figure it out on a case-by-case basis as we come up with problems to solve.

[zibi2]

@zibi2 Out of curiosity, are you developing a tool to try catching ABI changes between versions? We should probably chat about how to integrate this upstream, it would probably provide a lot of value if we can do it in a way that we minimize noise.

What I use is far from calling a tool. It involves running libc++ lit tests with both levels using -fdump-record-layouts-canonical option to dump the layout every class which is part of every single test. Then doing diff you will get many false positive which involves manual eye balling.