. Continued from a previous article.
It is in source file
adjust_wide_data, and the repeated lines are
567, 568, 576, 582. I tested and debugged with GNU
version 2.31, but these line numbers also apply to the sources of
In the do-while loop there, the enum variable
__codecvt_partial, so the loop never
I cannot propose a fix, because I don’t understand what this part
of the code is doing, and why it is necessary in the first place.
As I remarked
as I see it,
fseek should not involve any file reading
and buffer filling, nor buffer flushing and file writing, and also
any conversion of wide or multibyte characters should be unnecessary
at this stage. All that
fseek does in essence, is set
a position for future reading or writing operations.
Whether those operations are wide-character oriented or not, should
not make any difference.
The implementation should and could be simple, efficient, fast,
error-free and easy to maintain.
As I also wrote before, it is easy to say that without fully understanding all of the code. I am aware of that.
Still, when looking at how
is implemented in FreeBSD, I get the impression
it is much simpler and cleaner, and GNU in comparison is needlessly
complicated. Also, FreeBSD seems to do what it does for
without ever looking whether we are dealing with wide characters or not.
And that makes sense to me.
musl library does consider an invalid
So my trick using
getc() cannot be used here, it
skips too much. So in Siworin, I now always do
unless compiler symbol
__GLIBC__ is defined, then