;;
	"wasmer")
		exec wasmer run --dir=/ --env PWD="$PWD" --env PATH="$PATH" ${GOWASIRUNTIMEARGS:-} "$1" -- "${@:2}"
		;;
	"wazero")
		exec wazero run -mount /:/ -env-inherit -cachedir "${TMPDIR:-/tmp}"/wazero ${GOWASIRUNTIMEARGS:-} "$1" "${@:2}"
		;;
	"wasmtime" | "")

As of Go 1.23 (`winsymlink=1`), mount points no longer have [`os.ModeSymlink`](/pkg/os#ModeSymlink)
set, and reparse points that are not symlinks, Unix sockets, or dedup files now
always have [`os.ModeIrregular`](/pkg/os#ModeIrregular) set. As a result of these changes,
[`filepath.EvalSymlinks`](/pkg/path/filepath#EvalSymlinks) no longer evaluates
mount points, which was a source of many inconsistencies and bugs.

On Windows, [EvalSymlinks] no longer evaluates mount points,
which was a source of many inconsistencies and bugs.
This behavior is controlled by the `winsymlink` setting.
For Go 1.23, it defaults to `winsymlink=1`.
Previous versions default to `winsymlink=0`.

On Windows, [EvalSymlinks] no longer tries to normalize
volumes to drive letters, which was not always even possible.
This behavior is controlled by the `winreadlinkvolume` setting.

On Windows, the mode bits reported by [Lstat] and [Stat] for
reparse points changed. Mount points no longer have [ModeSymlink] set,
and reparse points that are not symlinks, Unix sockets, or dedup files
now always have [ModeIrregular] set.
This behavior is controlled by the `winsymlink` setting.
For Go 1.23, it defaults to `winsymlink=1`.

		switch err := recover().(type) {
		case nil:
			t.Fatal("bytes.Buffer.ReadFrom didn't panic")
		case error:
			// this is the error string of errNegativeRead
			wantError := "bytes.Buffer: reader returned negative count from Read"
			if err.Error() != wantError {
				t.Fatalf("recovered panic: got %v, want %v", err.Error(), wantError)
			}
		default:
			t.Fatalf("unexpected panic value: %#v", err)
		}
	}()

known to the system compiler (for example, all the GNU C extensions) as
well as the system-specific header locations and system-specific
pre-#defined macros. This is certainly possible to do, but it is an
enormous amount of work.

Cgo takes a different approach. It determines the meaning of C
identifiers not by parsing C code but by feeding carefully constructed
programs into the system C compiler and interpreting the generated

	if zt.File == nil {
		return
	}

	if z.Comment != zt.Comment {
		t.Errorf("comment=%q, want %q", z.Comment, zt.Comment)
	}
	if len(z.File) != len(zt.File) {
		t.Fatalf("file count=%d, want %d", len(z.File), len(zt.File))
	}

	// test read of each file
	for i, ft := range zt.File {
		readTestFile(t, zt, ft, z.File[i], raw)
	}
	if t.Failed() {
		return
	}

The shift operators shift the left operand by the shift count specified by the
right operand, which must be non-negative. If the shift count is negative at run time,
a <a href="#Run_time_panics">run-time panic</a> occurs.
The shift operators implement arithmetic shifts if the left operand is a signed
integer and logical shifts if it is an unsigned integer.
There is no upper limit on the shift count. Shifts behave

}

func TestCountNearPageBoundary(t *testing.T) {
	t.Parallel()
	b := dangerousSlice(t)
	for i := range b {
		c := Count(b[i:], []byte{1})
		if c != 0 {
			t.Fatalf("Count(b[%d:], {1})=%d, want 0\n", i, c)
		}
		c = Count(b[:i], []byte{0})
		if c != i {
			t.Fatalf("Count(b[:%d], {0})=%d, want %d\n", i, c, i)
		}
	}

)

// ErrTooLarge is passed to panic if memory cannot be allocated to store data in a buffer.
var ErrTooLarge = errors.New("bytes.Buffer: too large")
var errNegativeRead = errors.New("bytes.Buffer: reader returned negative count from Read")

const maxInt = int(^uint(0) >> 1)

// Bytes returns a slice of length b.Len() holding the unread portion of the buffer.
// The slice is valid for use only until the next buffer modification (that is,