Re: [AD] ungetc

[Matthew Leverton <meffer@xxxxxxxxxx>]

On Tue, Dec 21, 2010 at 11:48 PM, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> Does it really make sense for every file interface to define their own
> ungetc routine? Couldn't Allegro just handle a single universal one?
...
> Or alternatively, only if the ungetc hook is left null, is the above
> default implementation is used. Otherwise, drivers could fill it in
> and do something non-standard.
>
Attached is a patch that does this. memfile and PhysicsFS no longer
have their own implementation.

I'm not sure how stdio works when writing after ungetting, but with
this implementation, I just clear the ungetc buffer if that happens
and allow the function to write as normal. Seems like that's less
dangerous than trying to fseek backward to the virtual position
created by ungetc.

It also means you can kind of get around things like write-only
memfiles (i.e., you can read the unget characters), but I don't think
that sort of thing should be of any concern.

As far as I know, the only way people actually use this function is to
read immediately after doing an ungetc, in which case I think the
behavior will always be consistent where it matters.

On Wed, Dec 22, 2010 at 4:17 AM, Thomas Fjellstrom
<tfjellstrom@xxxxxxxxxx> wrote:
> I also agree with this. This way VFS drivers that actually
> have an ungetc can use that, like stdio.
>
> Unless of course that leads to too much variability, then it might make sense
> to use our own, but meh.
>
My thinking was the same. I left stdio alone in this version, but I
don't really have an opinion either way regarding which it should use.

--
Matthew Leverton

Attachment: ungetc.diff.gz
Description: GNU Zip compressed data