designing a filter interface for FILE*

[luser droog]

Two distinct feature-requests have conspired to produce
a requirement for my application (postscript interpreter
library) to support /interfaced/ FILE objects. So I'm
following my usual course: a public brainstorm.

So I need to make in internal `struct file` type with
variant subtypes, and `my_read()` and `my_write()` functions
which use `getchar()` and `putchar()` only on real FILE*
variants.

I also need a "mock file" which is backed by a counted
string. Currently, to accept a postscript program as
a `char *` argument, the library writes the string to
a temp file and then reads from the file. It does this
to avoid allocating the string contents in the PostScript
Virtual Memory, which was overburdened at the time these
decisions were made.

And suddenly, for the `eexec` operator, I need to make
a "filtered" file which performs Encryption on writes
and Decryption on reads.

BTW, check out the bizarre style of the functions from
the Adobe Type 1 Font spec:


unsigned short int r;
unsigned short int c1 = 52845;
unsigned short int c2 = 22719;

unsigned char Encrypt(plain) unsigned char plain;
{unsigned char cipher;
cipher = (plain ^ (r>>8));
r = (cipher + r) * c1 + c2;
return cipher;
}


thassright. zero indentation.


And here I fizzle out..

--
I know what to do but am afraid to do it.

[Keith Thompson]

luser droog <luser...@gmail.com> writes:
> Two distinct feature-requests have conspired to produce
> a requirement for my application (postscript interpreter
> library) to support /interfaced/ FILE objects. So I'm
> following my usual course: a public brainstorm.
>
> So I need to make in internal `struct file` type with
> variant subtypes, and `my_read()` and `my_write()` functions
> which use `getchar()` and `putchar()` only on real FILE*
> variants.
>
> I also need a "mock file" which is backed by a counted
> string.

[snip]

If you're able to assume POSIX support, take a look at fmemopen().
If you have further questions about fmemopen(), I suggest
comp.unix.programmer.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[luser droog]

On Wednesday, November 2, 2016 at 11:38:11 AM UTC-5, Keith Thompson wrote:
> luser droog <luser...@gmail.com> writes:
> > Two distinct feature-requests have conspired to produce
> > a requirement for my application (postscript interpreter
> > library) to support /interfaced/ FILE objects. So I'm
> > following my usual course: a public brainstorm.
> >
> > So I need to make in internal `struct file` type with
> > variant subtypes, and `my_read()` and `my_write()` functions
> > which use `getchar()` and `putchar()` only on real FILE*
> > variants.
> >
> > I also need a "mock file" which is backed by a counted
> > string.
> [snip]
>
> If you're able to assume POSIX support, take a look at fmemopen().
> If you have further questions about fmemopen(), I suggest
> comp.unix.programmer.
>

Much obliged. My friend Vincent was able to emulate it
for windows, so fmemopen presents a nice interface for
this.

Since you mention other groups, probably the ideal
place is
https://groups.google.com/forum/#!forum/xpost-discuss

So, see yall there, maybe. Sorry for the noise.