<feed xmlns='http://www.w3.org/2005/Atom'>
<title>go/src/runtime/os_netbsd.go, branch fix-runtime-test-GOMAXPROCS</title>
<subtitle>Fork of Go programming language with my patches.</subtitle>
<id>http://git.kilabit.info/go/atom?h=fix-runtime-test-GOMAXPROCS</id>
<link rel='self' href='http://git.kilabit.info/go/atom?h=fix-runtime-test-GOMAXPROCS'/>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/'/>
<updated>2025-07-11T21:27:24Z</updated>
<entry>
<title>runtime: gofmt after CL 643897 and CL 662455</title>
<updated>2025-07-11T21:27:24Z</updated>
<author>
<name>Tobias Klauser</name>
<email>tklauser@distanz.ch</email>
</author>
<published>2025-07-11T20:51:46Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=6ebb5f56d9ed35588970ce69cbad63508403bb8d'/>
<id>urn:sha1:6ebb5f56d9ed35588970ce69cbad63508403bb8d</id>
<content type='text'>
Change-Id: I3103325ebe29509c00b129a317b5708aece575a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/687715
Reviewed-by: Michael Pratt &lt;mpratt@google.com&gt;
Reviewed-by: Carlos Amedee &lt;carlos@golang.org&gt;
LUCI-TryBot-Result: Go LUCI &lt;golang-scoped@luci-project-accounts.iam.gserviceaccount.com&gt;
Auto-Submit: Tobias Klauser &lt;tobias.klauser@gmail.com&gt;
</content>
</entry>
<entry>
<title>runtime: rename ncpu to numCPUStartup</title>
<updated>2025-05-19T19:47:30Z</updated>
<author>
<name>Michael Pratt</name>
<email>mpratt@google.com</email>
</author>
<published>2025-05-13T17:12:47Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=db956262ac4125693cffb517ea7aebf6ab04ec35'/>
<id>urn:sha1:db956262ac4125693cffb517ea7aebf6ab04ec35</id>
<content type='text'>
ncpu is the total logical CPU count at startup. It is never updated. For
#73193, we will start using updated CPU counts for updated GOMAXPROCS,
making the ncpu name a bit ambiguous. Change to a less ambiguous name.

While we're at it, give the OS specific lookup functions a common name,
so it can be used outside of osinit later.

For #73193.

Change-Id: I6a6a636cf21cc60de36b211f3c374080849fc667
Reviewed-on: https://go-review.googlesource.com/c/go/+/672277
LUCI-TryBot-Result: Go LUCI &lt;golang-scoped@luci-project-accounts.iam.gserviceaccount.com&gt;
Reviewed-by: Michael Knyszek &lt;mknyszek@google.com&gt;
Auto-Submit: Michael Pratt &lt;mpratt@google.com&gt;
</content>
</entry>
<entry>
<title>runtime: cleanup M vgetrandom state before dropping P</title>
<updated>2025-04-03T08:25:08Z</updated>
<author>
<name>Michael Pratt</name>
<email>mpratt@google.com</email>
</author>
<published>2025-04-03T03:26:25Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=0b31e6d4cc804ab76ae8ced151ee2f50657aec14'/>
<id>urn:sha1:0b31e6d4cc804ab76ae8ced151ee2f50657aec14</id>
<content type='text'>
When an M is destroyed, we put its vgetrandom state back on the shared
list for another M to reuse. This list is simply a slice, so appending
to the slice may allocate. Currently this operation is performed in
mdestroy, after the P is released, meaning allocation is not allowed.

More the cleanup earlier in mdestroy when allocation is still OK.

Also add //go:nowritebarrierrec to mdestroy since it runs without a P,
which would have caught this bug.

Fixes #73141.

Change-Id: I6a6a636c3fbf5c6eec09d07a260e39dbb4d2db12
Reviewed-on: https://go-review.googlesource.com/c/go/+/662455
Reviewed-by: Jason Donenfeld &lt;Jason@zx2c4.com&gt;
LUCI-TryBot-Result: Go LUCI &lt;golang-scoped@luci-project-accounts.iam.gserviceaccount.com&gt;
Reviewed-by: Keith Randall &lt;khr@golang.org&gt;
Reviewed-by: Keith Randall &lt;khr@google.com&gt;
</content>
</entry>
<entry>
<title>runtime: migrate internal/atomic to internal/runtime</title>
<updated>2024-03-25T19:53:03Z</updated>
<author>
<name>Andy Pan</name>
<email>panjf2000@gmail.com</email>
</author>
<published>2024-02-01T02:21:14Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=4c2b1e0feb3d3112da94fa4cd11ebe995003fa89'/>
<id>urn:sha1:4c2b1e0feb3d3112da94fa4cd11ebe995003fa89</id>
<content type='text'>
For #65355

Change-Id: I65dd090fb99de9b231af2112c5ccb0eb635db2be
Reviewed-on: https://go-review.googlesource.com/c/go/+/560155
Reviewed-by: David Chase &lt;drchase@google.com&gt;
Reviewed-by: Michael Pratt &lt;mpratt@google.com&gt;
LUCI-TryBot-Result: Go LUCI &lt;golang-scoped@luci-project-accounts.iam.gserviceaccount.com&gt;
Reviewed-by: Ibrahim Bazoka &lt;ibrahimbazoka729@gmail.com&gt;
Auto-Submit: Emmanuel Odeke &lt;emmanuel@orijtech.com&gt;
</content>
</entry>
<entry>
<title>math/rand, math/rand/v2: use ChaCha8 for global rand</title>
<updated>2023-12-05T20:34:30Z</updated>
<author>
<name>Russ Cox</name>
<email>rsc@golang.org</email>
</author>
<published>2023-08-06T03:26:28Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=c29444ef39a44ad56ddf7b3d2aa8a51df1163e04'/>
<id>urn:sha1:c29444ef39a44ad56ddf7b3d2aa8a51df1163e04</id>
<content type='text'>
Move ChaCha8 code into internal/chacha8rand and use it to implement
runtime.rand, which is used for the unseeded global source for
both math/rand and math/rand/v2. This also affects the calculation of
the start point for iteration over very very large maps (when the
32-bit fastrand is not big enough).

The benefit is that misuse of the global random number generators
in math/rand and math/rand/v2 in contexts where non-predictable
randomness is important for security reasons is no longer a
security problem, removing a common mistake among programmers
who are unaware of the different kinds of randomness.

The cost is an extra 304 bytes per thread stored in the m struct
plus 2-3ns more per random uint64 due to the more sophisticated
algorithm. Using PCG looks like it would cost about the same,
although I haven't benchmarked that.

Before this, the math/rand and math/rand/v2 global generator
was wyrand (https://github.com/wangyi-fudan/wyhash).
For math/rand, using wyrand instead of the Mitchell/Reeds/Thompson
ALFG was justifiable, since the latter was not any better.
But for math/rand/v2, the global generator really should be
at least as good as one of the well-studied, specific algorithms
provided directly by the package, and it's not.

(Wyrand is still reasonable for scheduling and cache decisions.)

Good randomness does have a cost: about twice wyrand.

Also rationalize the various runtime rand references.

goos: linux
goarch: amd64
pkg: math/rand/v2
cpu: AMD Ryzen 9 7950X 16-Core Processor
                        │ bbb48afeb7.amd64 │           5cf807d1ea.amd64           │
                        │      sec/op      │    sec/op     vs base                │
ChaCha8-32                     1.862n ± 2%    1.861n ± 2%        ~ (p=0.825 n=20)
PCG_DXSM-32                    1.471n ± 1%    1.460n ± 2%        ~ (p=0.153 n=20)
SourceUint64-32                1.636n ± 2%    1.582n ± 1%   -3.30% (p=0.000 n=20)
GlobalInt64-32                 2.087n ± 1%    3.663n ± 1%  +75.54% (p=0.000 n=20)
GlobalInt64Parallel-32        0.1042n ± 1%   0.2026n ± 1%  +94.48% (p=0.000 n=20)
GlobalUint64-32                2.263n ± 2%    3.724n ± 1%  +64.57% (p=0.000 n=20)
GlobalUint64Parallel-32       0.1019n ± 1%   0.1973n ± 1%  +93.67% (p=0.000 n=20)
Int64-32                       1.771n ± 1%    1.774n ± 1%        ~ (p=0.449 n=20)
Uint64-32                      1.863n ± 2%    1.866n ± 1%        ~ (p=0.364 n=20)
GlobalIntN1000-32              3.134n ± 3%    4.730n ± 2%  +50.95% (p=0.000 n=20)
IntN1000-32                    2.489n ± 1%    2.489n ± 1%        ~ (p=0.683 n=20)
Int64N1000-32                  2.521n ± 1%    2.516n ± 1%        ~ (p=0.394 n=20)
Int64N1e8-32                   2.479n ± 1%    2.478n ± 2%        ~ (p=0.743 n=20)
Int64N1e9-32                   2.530n ± 2%    2.514n ± 2%        ~ (p=0.193 n=20)
Int64N2e9-32                   2.501n ± 1%    2.494n ± 1%        ~ (p=0.616 n=20)
Int64N1e18-32                  3.227n ± 1%    3.205n ± 1%        ~ (p=0.101 n=20)
Int64N2e18-32                  3.647n ± 1%    3.599n ± 1%        ~ (p=0.019 n=20)
Int64N4e18-32                  5.135n ± 1%    5.069n ± 2%        ~ (p=0.034 n=20)
Int32N1000-32                  2.657n ± 1%    2.637n ± 1%        ~ (p=0.180 n=20)
Int32N1e8-32                   2.636n ± 1%    2.636n ± 1%        ~ (p=0.763 n=20)
Int32N1e9-32                   2.660n ± 2%    2.638n ± 1%        ~ (p=0.358 n=20)
Int32N2e9-32                   2.662n ± 2%    2.618n ± 2%        ~ (p=0.064 n=20)
Float32-32                     2.272n ± 2%    2.239n ± 2%        ~ (p=0.194 n=20)
Float64-32                     2.272n ± 1%    2.286n ± 2%        ~ (p=0.763 n=20)
ExpFloat64-32                  3.762n ± 1%    3.744n ± 1%        ~ (p=0.171 n=20)
NormFloat64-32                 3.706n ± 1%    3.655n ± 2%        ~ (p=0.066 n=20)
Perm3-32                       32.93n ± 3%    34.62n ± 1%   +5.13% (p=0.000 n=20)
Perm30-32                      202.9n ± 1%    204.0n ± 1%        ~ (p=0.482 n=20)
Perm30ViaShuffle-32            115.0n ± 1%    114.9n ± 1%        ~ (p=0.358 n=20)
ShuffleOverhead-32             112.8n ± 1%    112.7n ± 1%        ~ (p=0.692 n=20)
Concurrent-32                  2.107n ± 0%    3.725n ± 1%  +76.75% (p=0.000 n=20)

goos: darwin
goarch: arm64
pkg: math/rand/v2
                       │ bbb48afeb7.arm64 │           5cf807d1ea.arm64            │
                       │      sec/op      │    sec/op     vs base                 │
ChaCha8-8                     2.480n ± 0%    2.429n ± 0%    -2.04% (p=0.000 n=20)
PCG_DXSM-8                    2.531n ± 0%    2.530n ± 0%         ~ (p=0.877 n=20)
SourceUint64-8                2.534n ± 0%    2.533n ± 0%         ~ (p=0.732 n=20)
GlobalInt64-8                 2.172n ± 1%    4.794n ± 0%  +120.67% (p=0.000 n=20)
GlobalInt64Parallel-8        0.4320n ± 0%   0.9605n ± 0%  +122.32% (p=0.000 n=20)
GlobalUint64-8                2.182n ± 0%    4.770n ± 0%  +118.58% (p=0.000 n=20)
GlobalUint64Parallel-8       0.4307n ± 0%   0.9583n ± 0%  +122.51% (p=0.000 n=20)
Int64-8                       4.107n ± 0%    4.104n ± 0%         ~ (p=0.416 n=20)
Uint64-8                      4.080n ± 0%    4.080n ± 0%         ~ (p=0.052 n=20)
GlobalIntN1000-8              2.814n ± 2%    5.643n ± 0%  +100.50% (p=0.000 n=20)
IntN1000-8                    4.141n ± 0%    4.139n ± 0%         ~ (p=0.140 n=20)
Int64N1000-8                  4.140n ± 0%    4.140n ± 0%         ~ (p=0.313 n=20)
Int64N1e8-8                   4.140n ± 0%    4.139n ± 0%         ~ (p=0.103 n=20)
Int64N1e9-8                   4.139n ± 0%    4.140n ± 0%         ~ (p=0.761 n=20)
Int64N2e9-8                   4.140n ± 0%    4.140n ± 0%         ~ (p=0.636 n=20)
Int64N1e18-8                  5.266n ± 0%    5.326n ± 1%    +1.14% (p=0.001 n=20)
Int64N2e18-8                  6.052n ± 0%    6.167n ± 0%    +1.90% (p=0.000 n=20)
Int64N4e18-8                  8.826n ± 0%    9.051n ± 0%    +2.55% (p=0.000 n=20)
Int32N1000-8                  4.127n ± 0%    4.132n ± 0%    +0.12% (p=0.000 n=20)
Int32N1e8-8                   4.126n ± 0%    4.131n ± 0%    +0.12% (p=0.000 n=20)
Int32N1e9-8                   4.127n ± 0%    4.132n ± 0%    +0.12% (p=0.000 n=20)
Int32N2e9-8                   4.132n ± 0%    4.131n ± 0%         ~ (p=0.017 n=20)
Float32-8                     4.109n ± 0%    4.105n ± 0%         ~ (p=0.379 n=20)
Float64-8                     4.107n ± 0%    4.106n ± 0%         ~ (p=0.867 n=20)
ExpFloat64-8                  5.339n ± 0%    5.383n ± 0%    +0.82% (p=0.000 n=20)
NormFloat64-8                 5.735n ± 0%    5.737n ± 1%         ~ (p=0.856 n=20)
Perm3-8                       26.65n ± 0%    26.80n ± 1%    +0.58% (p=0.000 n=20)
Perm30-8                      194.8n ± 1%    197.0n ± 0%    +1.18% (p=0.000 n=20)
Perm30ViaShuffle-8            156.6n ± 0%    157.6n ± 1%    +0.61% (p=0.000 n=20)
ShuffleOverhead-8             124.9n ± 0%    125.5n ± 0%    +0.52% (p=0.000 n=20)
Concurrent-8                  2.434n ± 3%    5.066n ± 0%  +108.09% (p=0.000 n=20)

goos: linux
goarch: 386
pkg: math/rand/v2
cpu: AMD Ryzen 9 7950X 16-Core Processor
                        │ bbb48afeb7.386 │            5cf807d1ea.386             │
                        │     sec/op     │    sec/op     vs base                 │
ChaCha8-32                  11.295n ± 1%    4.748n ± 2%   -57.96% (p=0.000 n=20)
PCG_DXSM-32                  7.693n ± 1%    7.738n ± 2%         ~ (p=0.542 n=20)
SourceUint64-32              7.658n ± 2%    7.622n ± 2%         ~ (p=0.344 n=20)
GlobalInt64-32               3.473n ± 2%    7.526n ± 2%  +116.73% (p=0.000 n=20)
GlobalInt64Parallel-32      0.3198n ± 0%   0.5444n ± 0%   +70.22% (p=0.000 n=20)
GlobalUint64-32              3.612n ± 0%    7.575n ± 1%  +109.69% (p=0.000 n=20)
GlobalUint64Parallel-32     0.3168n ± 0%   0.5403n ± 0%   +70.51% (p=0.000 n=20)
Int64-32                     7.673n ± 2%    7.789n ± 1%         ~ (p=0.122 n=20)
Uint64-32                    7.773n ± 1%    7.827n ± 2%         ~ (p=0.920 n=20)
GlobalIntN1000-32            6.268n ± 1%    9.581n ± 1%   +52.87% (p=0.000 n=20)
IntN1000-32                  10.33n ± 2%    10.45n ± 1%         ~ (p=0.233 n=20)
Int64N1000-32                10.98n ± 2%    11.01n ± 1%         ~ (p=0.401 n=20)
Int64N1e8-32                 11.19n ± 2%    10.97n ± 1%         ~ (p=0.033 n=20)
Int64N1e9-32                 11.06n ± 1%    11.08n ± 1%         ~ (p=0.498 n=20)
Int64N2e9-32                 11.10n ± 1%    11.01n ± 2%         ~ (p=0.995 n=20)
Int64N1e18-32                15.23n ± 2%    15.04n ± 1%         ~ (p=0.973 n=20)
Int64N2e18-32                15.89n ± 1%    15.85n ± 1%         ~ (p=0.409 n=20)
Int64N4e18-32                18.96n ± 2%    19.34n ± 2%         ~ (p=0.048 n=20)
Int32N1000-32                10.46n ± 2%    10.44n ± 2%         ~ (p=0.480 n=20)
Int32N1e8-32                 10.46n ± 2%    10.49n ± 2%         ~ (p=0.951 n=20)
Int32N1e9-32                 10.28n ± 2%    10.26n ± 1%         ~ (p=0.431 n=20)
Int32N2e9-32                 10.50n ± 2%    10.44n ± 2%         ~ (p=0.249 n=20)
Float32-32                   13.80n ± 2%    13.80n ± 2%         ~ (p=0.751 n=20)
Float64-32                   23.55n ± 2%    23.87n ± 0%         ~ (p=0.408 n=20)
ExpFloat64-32                15.36n ± 1%    15.29n ± 2%         ~ (p=0.316 n=20)
NormFloat64-32               13.57n ± 1%    13.79n ± 1%    +1.66% (p=0.005 n=20)
Perm3-32                     45.70n ± 2%    46.99n ± 2%    +2.81% (p=0.001 n=20)
Perm30-32                    399.0n ± 1%    403.8n ± 1%    +1.19% (p=0.006 n=20)
Perm30ViaShuffle-32          349.0n ± 1%    350.4n ± 1%         ~ (p=0.909 n=20)
ShuffleOverhead-32           322.3n ± 1%    323.8n ± 1%         ~ (p=0.410 n=20)
Concurrent-32                3.331n ± 1%    7.312n ± 1%  +119.50% (p=0.000 n=20)

For #61716.

Change-Id: Ibdddeed85c34d9ae397289dc899e04d4845f9ed2
Reviewed-on: https://go-review.googlesource.com/c/go/+/516860
Reviewed-by: Michael Pratt &lt;mpratt@google.com&gt;
Reviewed-by: Filippo Valsorda &lt;filippo@golang.org&gt;
LUCI-TryBot-Result: Go LUCI &lt;golang-scoped@luci-project-accounts.iam.gserviceaccount.com&gt;
</content>
</entry>
<entry>
<title>runtime: don't clear procid on netbsd</title>
<updated>2023-09-11T16:15:14Z</updated>
<author>
<name>Michael Pratt</name>
<email>mpratt@google.com</email>
</author>
<published>2023-09-08T21:59:02Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=298e8488646e25e62b3879b88958cf0672b5acac'/>
<id>urn:sha1:298e8488646e25e62b3879b88958cf0672b5acac</id>
<content type='text'>
This is a partial revert of CL 526118.

NetBSD uses mp.procid in locking (semawake). unminit is called
surprisingly early in mexit, and there is definitely locking after that
point, so it isn't safe to clear procid so early.

Fixes #62524.
Fixes #62531.

Change-Id: Iefbef63e84fc0395e255970a301401e1187a910d
Reviewed-on: https://go-review.googlesource.com/c/go/+/527057
Reviewed-by: Benny Siegert &lt;bsiegert@gmail.com&gt;
Auto-Submit: Michael Pratt &lt;mpratt@google.com&gt;
LUCI-TryBot-Result: Go LUCI &lt;golang-scoped@luci-project-accounts.iam.gserviceaccount.com&gt;
Reviewed-by: Cherry Mui &lt;cherryyz@google.com&gt;
</content>
</entry>
<entry>
<title>runtime: clear procid in unminit</title>
<updated>2023-09-06T18:36:02Z</updated>
<author>
<name>Michael Pratt</name>
<email>mpratt@google.com</email>
</author>
<published>2023-09-06T14:31:32Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=4be921d888d3a68c51e38d4c615a4438c7b2cb30'/>
<id>urn:sha1:4be921d888d3a68c51e38d4c615a4438c7b2cb30</id>
<content type='text'>
Extra Ms can move between system threads. needm will reinitialize procid
(via minit) on the new thread, but leaving a stale procid behind after
dropm can be misleading if printing the M early in needm for debugging.

Change-Id: I668891971a0baeab31170d1e40a97126416e7379
Reviewed-on: https://go-review.googlesource.com/c/go/+/526118
Reviewed-by: Cherry Mui &lt;cherryyz@google.com&gt;
Auto-Submit: Michael Pratt &lt;mpratt@google.com&gt;
Reviewed-by: Michael Knyszek &lt;mknyszek@google.com&gt;
LUCI-TryBot-Result: Go LUCI &lt;golang-scoped@luci-project-accounts.iam.gserviceaccount.com&gt;
</content>
</entry>
<entry>
<title>runtime: implement SUID/SGID protections</title>
<updated>2023-06-06T18:49:01Z</updated>
<author>
<name>Roland Shoemaker</name>
<email>bracewell@google.com</email>
</author>
<published>2023-05-09T18:47:57Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=2496653d0a5c6c26b879bb5bdd135e1f7504e051'/>
<id>urn:sha1:2496653d0a5c6c26b879bb5bdd135e1f7504e051</id>
<content type='text'>
On Unix platforms, the runtime previously did nothing special when a
program was run with either the SUID or SGID bits set. This can be
dangerous in certain cases, such as when dumping memory state, or
assuming the status of standard i/o file descriptors.

Taking cues from glibc, this change implements a set of protections when
a binary is run with SUID or SGID bits set (or is SUID/SGID-like). On
Linux, whether to enable these protections is determined by whether the
AT_SECURE flag is passed in the auxiliary vector. On platforms which
have the issetugid syscall (the BSDs, darwin, and Solaris/Illumos), that
is used. On the remaining platforms (currently only AIX) we check
!(getuid() == geteuid() &amp;&amp; getgid == getegid()).

Currently when we determine a binary is "tainted" (using the glibc
terminology), we implement two specific protections:
  1. we check if the file descriptors 0, 1, and 2 are open, and if they
     are not, we open them, pointing at /dev/null (or fail).
  2. we force GOTRACKBACK=none, and generally prevent dumping of
     trackbacks and registers when a program panics/aborts.

In the future we may add additional protections.

This change requires implementing issetugid on the platforms which
support it, and implementing getuid, geteuid, getgid, and getegid on
AIX.

Thanks to Vincent Dehors from Synacktiv for reporting this issue.

Fixes #60272
Fixes CVE-2023-29403

Change-Id: I73fc93f2b7a8933c192ce3eabbf1db359db7d5fa
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1878434
Reviewed-by: Damien Neil &lt;dneil@google.com&gt;
Reviewed-by: Ian Lance Taylor &lt;iant@google.com&gt;
Run-TryBot: Roland Shoemaker &lt;bracewell@google.com&gt;
Reviewed-by: Russ Cox &lt;rsc@google.com&gt;
Reviewed-on: https://go-review.googlesource.com/c/go/+/501223
Run-TryBot: David Chase &lt;drchase@google.com&gt;
Reviewed-by: Michael Knyszek &lt;mknyszek@google.com&gt;
TryBot-Result: Gopher Robot &lt;gobot@golang.org&gt;
</content>
</entry>
<entry>
<title>runtime: consolidate on a single closeonexec definition</title>
<updated>2023-05-20T21:27:51Z</updated>
<author>
<name>Ian Lance Taylor</name>
<email>iant@golang.org</email>
</author>
<published>2023-05-20T00:44:35Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=58315a771a645359d2173f9555d4a606e6613158'/>
<id>urn:sha1:58315a771a645359d2173f9555d4a606e6613158</id>
<content type='text'>
Now that we implement fcntl on all Unix systems, we can
write closeonexec that uses it. This lets us remove a bunch
of assembler code.

Change-Id: If35591df535ccfc67292086a9492f0a8920e3681
Reviewed-on: https://go-review.googlesource.com/c/go/+/496081
Reviewed-by: Brad Fitzpatrick &lt;bradfitz@golang.org&gt;
Run-TryBot: Ian Lance Taylor &lt;iant@google.com&gt;
Run-TryBot: Ian Lance Taylor &lt;iant@golang.org&gt;
Auto-Submit: Ian Lance Taylor &lt;iant@google.com&gt;
TryBot-Result: Gopher Robot &lt;gobot@golang.org&gt;
Reviewed-by: Bryan Mills &lt;bcmills@google.com&gt;
Reviewed-by: Ian Lance Taylor &lt;iant@google.com&gt;
</content>
</entry>
<entry>
<title>runtime: change fcntl to return two values</title>
<updated>2023-05-20T20:32:54Z</updated>
<author>
<name>Ian Lance Taylor</name>
<email>iant@golang.org</email>
</author>
<published>2023-05-19T04:13:03Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=10532fdb141ae80140cd0f14637b9fe82f379688'/>
<id>urn:sha1:10532fdb141ae80140cd0f14637b9fe82f379688</id>
<content type='text'>
Separate the result and the errno value, rather than assuming
that the result can never be negative.

Change-Id: Ib01a70a3d46285aa77e95371cdde74e1504e7c12
Reviewed-on: https://go-review.googlesource.com/c/go/+/496416
Run-TryBot: Ian Lance Taylor &lt;iant@golang.org&gt;
Run-TryBot: Ian Lance Taylor &lt;iant@google.com&gt;
TryBot-Result: Gopher Robot &lt;gobot@golang.org&gt;
Reviewed-by: Ian Lance Taylor &lt;iant@google.com&gt;
Reviewed-by: Bryan Mills &lt;bcmills@google.com&gt;
Auto-Submit: Ian Lance Taylor &lt;iant@google.com&gt;
</content>
</entry>
</feed>
