Plan for string formatting?

[Avi Drissman]

I'm cleaning up the NS format strings for printf (https://crrev.com/c/8135159), but I'm wondering where we are with string formatting.

Right now, base::StringPrintf is just a wrapper around absl::StrFormat and there's a bug (https://crbug.com/40241565) to remove the wrapper. But StrFormat is just as memory-unsafe as StringPrintf was.

We also have base::StrCat but that only works for string-like things, so you need to throw an occasional base::NumberToString in there. absl::StrCat is better and doesn't require that.

But we also have a bug https://crbug.com/367401485 about moving to either {fmt} or std::format().

Given the push for memory safety, is there a path towards picking one and migrating?

Avi

[Jan Wilken Dörrie]

> But StrFormat is just as memory-unsafe as StringPrintf was.

Neither of them are memory unsafe. Both ensure the format string is a compile time constant and the types of the arguments match.

The abseil string functions are great, but only work for std::strings. std::u16string and std::wstring are generally not supported, which is likely a deal-breaker for Chromium.

While std::format does support std::string and std::wstring, it also does not support std::u16string: https://en.cppreference.com/cpp/utility/format/format

This leaves fmtlib, which added support for std::u16string back in 2018: https://github.com/fmtlib/fmt/issues/698

So I'd vote we prioritize https://crbug.com/367401485 and migrate to {fmt}.

Best,

Jan

[Leszek Swirski]

I'm fully supportive of migrating to {fmt} and would be willing to put in some legwork here. I had started a thread with ATLs a few years back for it and at the time there was vague support, I'm not sure if there has been a temperature change on third party deps since then though.

[Alexei Svitkine]

> The abseil string functions are great, but only work for std::strings. std::u16string and std::wstring are generally not supported, which is likely a deal-breaker for Chromium.

What about extending the abseil string functions to support those types? Or maintaining our own version with the same API/semantics if abseil is not willing to take those changes.
For teams that also work in other codebases that use abseil (e.g. Google server-side), it would be nice to have the same API semantics.

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/fb85a5eb-aff8-48c7-87c7-7b471df268fen%40chromium.org.

[K. Moon]

Given that a substantial fraction of Chromium developers don't work and never will work on Google-internal code, I don't think we should privilege Abseil for that reason specifically.

I believe fmt has the advantage of wider adoption in the browser C++ ecosystem (std::format is famously derived from it, after all), which I think is a nice benefit. But I don't have hard evidence favoring one or the other.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAKFU2SAbjd7gRzM84asGoYogyRdmgsDGQRx1U3FVYagQD%3DpMqg%40mail.gmail.com.

[K. Moon]

Correction: "browser C++ ecosystem" should have been "wider C++ ecosystem".

[Avi Drissman]

I'd be happy to have us move to {fmt}; the less we diverge from the larger ecosystem, the better. I would imagine we'd also want to migrate from base::StrCat as well, so as to have One Way of string formatting/building.

Avi