buffer: auto random fill Buffer(num) and new Buffer(num)

[jasnell]

@addaleax @nodejs/ctc ...

This PR does a couple things as a proposal to bring some closure to #9531

• As suggested by @addaleax, a pseudo-random byte value is selected at startup and used to auto-fill new Buffer(num) and Buffer(num).

• A new --pending-deprecation command-line flag and NODE_PENDING_DEPRECATION=1 environment variable is added that allows conditional off-by-default pending deprecation warnings.

• A pending deprecation warning is added for Buffer() and new Buffer(). This is off by default and will only be emitted when the new command line flag is set.

These are separated out into multiple commits.

There is a definite significant performance hit to new Buffer(num) and Buffer(num) using this.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

Affected core subsystem(s)

buffer

[addaleax]

You’ll need a mem != nullptr check around this ;)

[jasnell]

doh... I always forget about that.

[addaleax]

Hm, my first intuition is that a flag specifically for the buffer constructor itself, or specific to security-related API usage, would be better than one for general “pending” deprecations?

[addaleax]

Part of the performance hit might be that this stops using pooled allocation. Is that intentional?

[jasnell]

Yes, but it needn't I suppose. This was largely just to keep it simple and consistent. If we happen to pull off the pooled allocation, do you imagine we would just zero fill or use the randomly selected value to fill?

[addaleax]

@jasnell The best way that comes to mind for me right now is to have separate pools for uninitialized & for random-filled Buffers … alternatively, we could just keep using Buffer.allocUnsafe() here and fill manually.

[jasnell]

Yeah. I'm leaning in that direction to be honest (specifically, using Buffer.alloc(size, fill)). It would be much less disruptive and wouldn't require the underlying c/c++ change. I did it this way first to see what the perf would be like and it is way too much of a hit

[jasnell]

I'm going to open a second PR that uses this other method. I'd like us to get some comparison benchmark runs on various platforms. Definitely think going with the alloc then fill in js is going to be the better option tho.

[jasnell]

Regarding the flag, I'd really rather not have yet another special-case buffer-specific flag but certainly not completely opposed to it.

[ChALkeR]

@jasnell, note that #7152 had some prototype changes to avoid breaking valid usecases. Is that concern still applicable? /cc @seishun

[seishun]

There is a definite significant performance hit to new Buffer(num) and Buffer(num) using this.

It should be noted that this makes it a breaking change for performance-critical applications, and by introducing it in 8.0.0 we won't be giving people time to migrate as described in our deprecation policy.

This isn't to say that this is necessarily a bad solution, but I think it's an important fact that shouldn't be overlooked.

[ChALkeR]

This currently prints a warning on Buffer.alloc(10).map(x => x + 1).

It shouldn't do that. (Perhaps include that as a testcase?)

@seishun had some work-around in #7152, but I didn't check that one.

[jasnell]

I'm going to close this one in favor of the alternate which is much less disruptive overall and has a better perf profile.