[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: implementing fmemopen, open_memstream

From: Bruce Korb
Subject: Re: implementing fmemopen, open_memstream
Date: Mon, 22 Feb 2021 11:22:31 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0


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]


[1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdio.h.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

Attachment: Hover-fly.jpg
Description: JPEG image

reply via email to

[Prev in Thread] Current Thread [Next in Thread]