rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (04/08/90)
Further investigation found that the documentation for this function allows
the first 2 arguments to be defined in an implementation specific manner.
The (R4) documentation states that arguments must be a file descriptor and
a selection of XtInput{Read,Write,Except}Mask on POSIX-based systems, but
that they can vary for other operating systems. Is it bad to support other
OSes?
Just how portable is
an X program going to be, if it uses POSIX or X/Open programming standards?
It should be portable to other POSIX systems. Does VMS claim POSIX compliance?swick@ATHENA.MIT.EDU (Ralph R. Swick) (04/09/90)
Further investigation found that the documentation for this function allows the
first 2 arguments to be defined in an implementation specific manner.
Precisely because Xlib/Xt wants to define interfaces that are _useable_
on more than just POSIX systems. In theory, alternate input sources
could be much broader than just files.
Under VMS the XtAddInput function is expected to have an EventFlagNumber and
an IOStatusBlock as the first 2 arguments,
I would agree that VMS botched it (since I wasn't part of the decision :-).
Even though the AST mechanism is much better than what we've got with U*x,
since VMS does support all the C i/o functions it would have been more
prudent to implement the interface to XtAddInput as an extension to the
POSIX interface rather than as a replacement.
My question is, "Why are some of the Xt functions allowed to be implementation
defined, but not require all flavors of possible use?"
The spec does give an explicit interpretation for POSIX-compliant
systems. There is no reason to require non-POSIX systems to define
a completely different interface just because they might not be able
to produce integer file descriptors. The (perhaps naive) hope was
that other implementations would at least be internally consistent
with whatever interfaces the application uses to procure a
"file" descriptor.
-Ralph.