Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement atari fgetpos and fsetpos using NOTE/POINT #334

Open
mysterymath opened this issue Jun 2, 2024 · 7 comments
Open

Implement atari fgetpos and fsetpos using NOTE/POINT #334

mysterymath opened this issue Jun 2, 2024 · 7 comments
Assignees
Labels
enhancement New feature or request p2

Comments

@mysterymath
Copy link
Member

mysterymath commented Jun 2, 2024

The Atari DOS NOTE/POINT functionality isn't expressive enough to implement fseek, since the former use sector/offset, while the latter uses byte offsets from start/end of file. It is expressive enough to implement fgetpos and fsetpos, since these operate on an opaque fpos_t value, which could be interpreted as a sector/offset pair.

@mysterymath mysterymath added enhancement New feature or request p2 labels Jun 2, 2024
@mysterymath mysterymath changed the title Implement atari fgetpos and fsetpos using NOTE/POINT Implement atari fgetpos and fsetpos using NOTE/POINT Jun 2, 2024
@pfusik
Copy link
Contributor

pfusik commented Jun 19, 2024

I'd like to implement this.

@pfusik
Copy link
Contributor

pfusik commented Jun 20, 2024

How to handle FILE buffer?
NOTE will tell us sector/offset after the whole buffer we read.
Writing is easier: just flush the buffer, then NOTE.

I can only think of using NOTE at every entry of fill_buffer. The time overhead should be acceptable. Unfortunately, that grows all binaries that do not use fgetpos.
Then fsetpos does a POINT followed by skipping as many bytes as we had in the buffer. Possibly by just filling the buffer and moving the pointer.

@mysterymath
Copy link
Member Author

NOTE-ing on every fill_buffer SGTM; there's already quite a bit of stuff brought in just for standards compliance, and it shouldn't break the bank comparatively.

@pfusik
Copy link
Contributor

pfusik commented Jun 20, 2024

I'm thinking of:

typedef struct {
    unsigned short sector;          // at the beginning of the buffer
    unsigned char offset_in_sector; // at the beginning of the buffer
    size_t offset_in_buffer;        // size_t because of setvbuf
} fpos_t;

@mysterymath
Copy link
Member Author

I'm thinking of:

typedef struct {
    unsigned short sector;          // at the beginning of the buffer
    unsigned char offset_in_sector; // at the beginning of the buffer
    size_t offset_in_buffer;        // size_t because of setvbuf
} fpos_t;

Providing a custom fpos_t type per target may be... tricky, since stdio-full.c is currently built as part of common. But code also currently assumes that it's a file offset, and that's probably not tenable long-term. Some design and experimentation work is probably prudent around this.

@pfusik
Copy link
Contributor

pfusik commented Jun 20, 2024

Another idea (in pseudocode):

int fgetpos(FILE *stream, fpos_t *pos)
{
    if (stream->bufidx == 0)
        *pos = stream->position_at_last_fill_buffer;
    else {
        POINT(stream->position_at_last_fill_buffer);
        SKIP(stream->bufidx); // implemented as READ to buffer
        *pos = NOTE();
    }
}

This only needs 24-bit fpos_t.
For the default BUFSIZ=256 it would re-read a sector or two. But no need to do that in fsetpos.

@pfusik
Copy link
Contributor

pfusik commented Aug 11, 2024

I started coding it. Shall I add a fpos_t field in FILE ?
My first thought was repurposing the pos field, but that would break ftell.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request p2
Projects
None yet
Development

No branches or pull requests

2 participants