Some findings about non-blocking

[WeidiDeng]

After #167 was reverted, I found something about some peculiarities I want to share,

 import "os"
 
 func ioctl(f *os.File, cmd, ptr uintptr) error {
-       return ioctlInner(f.Fd(), cmd, ptr) // Fall back to blocking io.
-}
-
-// NOTE: Unused. Keeping for reference.
-func ioctlNonblock(f *os.File, cmd, ptr uintptr) error {
        sc, e := f.SyscallConn()
        if e != nil {
                return ioctlInner(f.Fd(), cmd, ptr) // Fall back to blocking io (old behavior).
        }

If this patch is applied, sometimes I can observe ping is written out to the output

/go/src/pty # go test -count=100 -timeout=30s
pingpanic: test timed out after 30s
        running tests:
                TestOpenByName (19s)

It's actually written here

pty/doc_test.go

Lines 42 to 44 in edfbf75

	text := []byte("ping")
	n, err := ttyFile.Write(text) // Write the text to the manually open tty.

Somehow, the slave device to my current terminal is opened.

I added some debug output here, and found out no error is returned and n is not changed. The resulting path /dev/pts/0 does refer to my terminal.

pty/pty_linux.go

Lines 41 to 48 in edfbf75

	func ptsname(f *os.File) (string, error) {
	var n _C_uint
	err := ioctl(f, syscall.TIOCGPTN, uintptr(unsafe.Pointer(&n))) //nolint:gosec // Expected unsafe pointer for Syscall call.
	if err != nil {
	return "", err
	}
	return "/dev/pts/" + strconv.Itoa(int(n)), nil
	}

I added some retries here that if n == 0 retry and the tests passed. But I feel this is a hack. I wonder why the syscall succeeded but the parameter passed didn't change?

[WeidiDeng]

This behavior can also be observed if the following path is applied,

 package pty
 
-import "os"
+import (
+       "os"
+       "time"
+)
 
 func ioctl(f *os.File, cmd, ptr uintptr) error {
+       time.Sleep(time.Microsecond)
        return ioctlInner(f.Fd(), cmd, ptr) // Fall back to blocking io.
 }

Somehow, adding a small delay also causes this.

I can not find anything about TIOCGPTN not changing the parameter while ioctl syscall succeeds online.

[WeidiDeng]

@creack Do you have time to take a look at this?

[WeidiDeng]

I believe it's the result of incorrect usage of conversion between unsafe.Pointer and uintptr.

Per the docs for unsafe.Pointer

(4) Conversion of a Pointer to a uintptr when calling functions like syscall.Syscall.

The Syscall functions in package syscall pass their uintptr arguments directly to the operating system, which then may, depending on the details of the call, reinterpret some of them as pointers. That is, the system call implementation is implicitly converting certain arguments back from uintptr to pointer.

If a pointer argument must be converted to uintptr for use as an argument, that conversion must appear in the call expression itself:

syscall.Syscall(SYS_READ, uintptr(fd), uintptr(unsafe.Pointer(p)), uintptr(n))

By manually hacking the function signature and converting the type to uintptr at the syscall.Syscall site, the problem is gone.