[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: implementing fmemopen, open_memstream
From: |
Bruno Haible |
Subject: |
Re: implementing fmemopen, open_memstream |
Date: |
Mon, 22 Feb 2021 03:21:13 +0100 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-201-generic; KDE/5.18.0; x86_64; ; ) |
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
Re: new module 'string-buffer', Bruno Haible, 2021/02/27