Package ghidra.pty.unix
Interface Util
- All Superinterfaces:
com.sun.jna.Library
public interface Util
extends com.sun.jna.Library
The interface for linking to
openpty via jna
See the UNIX manual pages
-
Nested Class Summary
Nested classes/interfaces inherited from interface com.sun.jna.Library
com.sun.jna.Library.Handler -
Field Summary
FieldsModifier and TypeFieldDescriptionstatic final UtilThe bare library without error handlingstatic final UtilFields inherited from interface com.sun.jna.Library
OPTION_ALLOW_OBJECTS, OPTION_CALLING_CONVENTION, OPTION_CLASSLOADER, OPTION_FUNCTION_MAPPER, OPTION_INVOCATION_MAPPER, OPTION_OPEN_FLAGS, OPTION_STRING_ENCODING, OPTION_STRUCTURE_ALIGNMENT, OPTION_SYMBOL_PROVIDER, OPTION_TYPE_MAPPER -
Method Summary
Modifier and TypeMethodDescriptionintopenpty(com.sun.jna.ptr.IntByReference amaster, com.sun.jna.ptr.IntByReference aslave, com.sun.jna.Pointer name, com.sun.jna.Pointer termp, com.sun.jna.Pointer winp)
-
Field Details
-
BARE
The bare library without error handlingFor error handling, use
INSTANCE, or check for errors manually, perhaps usingErr.We cannot just use
throwsLastErrorExceptionto handle errors, because the idiom it applies is not correct for errno on UNIX. See https://man7.org/linux/man-pages/man3/errno.3.html, in particular:The value in errno is significant only when the return value of the call indicated an error (i.e., -1 from most system calls; -1 or NULL from most library functions); a function that succeeds is allowed to change errno.
This actually happens on our test setup when invoking the native
openptyfrom a Docker container. It returns 0, but sets errno. JNA will incorrectly interpret this as failure. -
INSTANCE
-
-
Method Details
-
openpty
int openpty(com.sun.jna.ptr.IntByReference amaster, com.sun.jna.ptr.IntByReference aslave, com.sun.jna.Pointer name, com.sun.jna.Pointer termp, com.sun.jna.Pointer winp)
-