Re: implementing fmemopen, open_memstream

[Bruce Korb]

Hi,

On 2/21/21 6:21 PM, Bruno Haible wrote:
> 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.
:) The level of incompetence at SCO still blows my mind. I left when 
half got sold to Sun and the other acquired by Caldera.
> > One option is to wrap all of the file pointer functions in stdio
> >
> > Yes, this approach would work in theory. We have used this approach
> > ...
> >
> > And it would be not just "a bit of work", but huge work, because
:) Sorry. I tend to use understatement too much.
> >    - 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.
That would be part of the "bit of work" part. You'd also have to fiddle 
stuff so that gl_FILE* value was never conflicted with stdin, stdout or 
stderr.
> > 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

My actual approach is that I'm retired and nobody pays me to do this 
stuff anymore. It's why my projects get updated infrequently. Instead, I 
take pictures and play with Photoshop. :)

Cheers - Bruce

Hover-fly.jpg
Description: JPEG image