Second attempt at introducing SafeSPrintf().

Second attempt at introducing SafeSPrintf().
See original discussion at https://codereview.chromium.org/18656004/
Reverted as: https://codereview.chromium.org/23463010/

Added a new base::strings::SafeSPrintf() function that can
safely be called from all restricted (e.g. async-signal-safe)
environments. It is roughly equivalent to snprintf(). But
it is easier to use, as it uses C++ to be type-safe.

In release builds, this function is guaranteed to never call
any other library function nor any system calls. In debug
builds, we call RAW_CHECK() in some circumstances.

This code is needed for (at least) the seccomp sandbox and
to clean up code in the stack tracer. Those changes are
pending and will be submitted as separate CLs.

BUG=285499
TEST=base_unittests
TBR=willchan@chromium.org
NOTRY=true

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=221322

[jln (very slow on Chromium), 2013-09-05 00:27:57]

lgtm

[commit-bot: I haz the power, 2013-09-05 00:41:26]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/markus@chromium.org/23777003/23001

[commit-bot: I haz the power, 2013-09-05 00:43:53]

Change committed as 221322

[Nico, 2013-12-05 21:15:22]

Hello,

I'm not a fan of the C++11-specific things in this CL. We don't really use C++11
yet, and adding stuff like this adds a maintenance cost (e.g.
https://codereview.chromium.org/107173002/) without much benefit at the moment.
Can we revert the C++11-only bits please?

[willchan no longer on Chromium, 2013-12-05 21:27:29]

Yes, it's fine to remove.

That said, I'm surprised it's adding a maintenance cost. Is the code wrong? Or
is the C++11 mode of g++ broken?

[Nico, 2013-12-05 21:31:00]

On Thu, Dec 5, 2013 at 1:27 PM, <willchan@chromium.org> wrote:

> Yes, it's fine to remove.
>
> That said, I'm surprised it's adding a maintenance cost. Is the code
> wrong? Or
> is the C++11 mode of g++ broken?
>

We don't have bots that build in C++11 mode with gcc yet, and likely won't
for some time. But some folks apparently want to play with that locally and
then write CLs to fix gcc-C++11-mode workarounds, which wouldn't be needed
if this wasn't here.


>
> https://chromiumcodereview.appspot.com/23777003/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[willchan no longer on Chromium, 2013-12-05 21:34:08]

Sorry, I was misleading. Yeah, I understand why it's a maintenance cost. But I
don't understand why it broke. Is it gcc's fault?

And yeah, let's go ahead and kill this code if it's causing problems.

[Nico, 2013-12-05 21:36:31]

On Thu, Dec 5, 2013 at 1:34 PM, <willchan@chromium.org> wrote:

> Sorry, I was misleading. Yeah, I understand why it's a maintenance cost.
> But I
> don't understand why it broke. Is it gcc's fault?
>

I don't know if gcc is right rejecting this or clang is right accepting it.
The compile error is at https://codereview.chromium.org/107173002/#msg1


>
> And yeah, let's go ahead and kill this code if it's causing problems.
>
> https://chromiumcodereview.appspot.com/23777003/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.