Hi Bruce,
> On 2/21/21 3:07 PM, Bruno Haible wrote:
> > What do you do on
> > AIX, HP-UX, Solaris, OpenServer, UnixWare, native Windows ?
> > Their stdio implementation does not contain function pointers in structs.
>
> Also, I worked for SCO and when it committed seppuku with bad lawyering
> it pretty much put OpenServer and UnixWare on life support, if that. Who
> would still be writing stuff for those platforms? :)
Let's talk about the important platforms in this list, not the unimportant
ones. AIX and Solaris and possibly Windows. A portability module would
not deserve this title if it doesn't work on AIX and Solaris.
> One option is to wrap all of the file pointer functions in stdio and
> have the wrapper look for when it needs to call the wrapped function vs.
> calling registered functions. That's a bit of work, but it could be
> gotten to work. Otherwise, it means you can't do a drop-in fopen
> replacement that works on strings. Having a consistent implementation
> that works on the first two sets of platforms is about as good as one
> can do in that case.
Yes, this approach would work in theory. We have used this approach
(overriding an object type) for 'struct stat', and noticed that it has
problems. Namely when a library offers an API that contains 'FILE *'
arguments, you cannot just pass a 'gl_FILE *' to a function that
expects a 'FILE *', and similarly for return types.
And it would be not just "a bit of work", but huge work, because
- there are many functions that operate on FILE [1],
- some of the functions are overridden for other purposes
(*printf bugs, LARGEFILE, etc.), and you would need to make sure
that the overrides don't conflict.
So, I think source-code compatibility with the 'FILE *' type is too
constraining. In GNU libtextstyle, I've therefore taken an object-
oriented approach to streams. [2]
Bruno
[1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdio.h.html
[2]
https://www.gnu.org/software/gettext/libtextstyle/manual/html_node/The-output-stream-hierarchy.html
