@masatake AFAICT there is no difference between latest git ctags [mio.c](https://github.com/universal-ctags/ctags/blob/master/main/mio.c) and latest git Geany [mio.c](https://github.com/geany/geany/blob/master/ctags/main/mio.c).

There is no other mio.c used in Geany.

In ctags, I have a plan to remove code using 'fpos_t' (https://github.com/universal-ctags/ctags/issues/3727). ctags may use only mio_seek and mio_tell.

AFAICT `fpos_t` does not leak from ctags into Geany, [this](https://github.com/geany/geany/blob/d6ce258cec790da1e81db48476507bb114c7e482...) is the only occurrence in the Geany repository (other than a comment). Perhaps we don't use languages that need it?

So Geany probably doesn't care, but the experts I pinged above should confirm.

Just a comment, `fpos_t` is not simply a [number](https://en.cppreference.com/w/c/io/fpos_t), it is a structure that has other information about the state as well as the offset, so its risky to assign the result of any function returning `fpos_t` to a number or to pass just an offset to any function expecting `fpos_t`. I guess thats why mio defines its position as a union of size_t and `fpos_t`.

Thank you. How about long returned from mio_tell and passed to mio_seek? I will introduce mio_long or mio_off_t. Is this acceptable?

We don't use MIO at all in Geany itself - its only use is through ctags and we don't call any of its API directly. So you can do whatever you want with it in ctags.

Historically, when MIO wasn't part of ctags, we used to replace all occurrences of `FILE` with `MIO` in ctags and pass the editor's buffer as MIO. But since MIO is now part of ctags, we just call

``` extern bool parseRawBuffer(const char *fileName, unsigned char *buffer, size_t bufferSize, const langType language, void *clientData) ```

and let ctags handle all the MIO stuff.

Closed #3510 as completed.