Re: [Libcdio-devel] [PATCH v3 0/2] Add Rock Ridge CE record processing

[Thomas Schmitt]

Hi,

i think that the chnages are ripe for being accepted and thus pushed
branch "pete_batard_ce_v3".
Rocky, please merge.

-
Tests made:

"git am" applied the v3 patches without complaints.
Both known problems of v2 are gone:

- The gcc complaint about mixed code and declarations does not appear
  any more.

- The run of iso-info with the ISO which contains the CE entries with
  offset larger than 255 does not SIGSEGV any more:

iso-info --no-joliet \
 -i firmware-bookworm-DI-alpha1-amd64-netinst.iso \
 -l

  It produces 3892 output lines instead of less than 600 with v2.

  (I guess any Debian installation ISO from last year for amd64 with
   non-free firmware can serve as test object.
   But a recent change in debian-cd will avoid the softlinks which
   fill up a CE block by their target strings.)

The anticipated problem of patch v1 is indeed avoided:

- I verified by an intentionally manipulated ISO that the patch correctly
  handles the case that a CE entry is not the last entry in its system use
  area:

iso-info --no-joliet -i iso9660_early_ce.iso

  yields
2 /RockRidgeName:x
  The code in branch "master" yields the same name by just ignoring the
  CE entry. But the v1 patch would have yielded something derived from
  the dull name "ROCKRIDG.;1", because it would have hopped away from
  the NM entry which carries "RockRidgeName:x".

  The file iso9660_early_ce.iso was made for GRUB. That patch is still
  pending. Instructions how to craft this ISO are in
https://lists.gnu.org/archive/html/grub-devel/2023-03/msg00032.html
  The file iso9660_early_ce.iso.gz is included as "IT binary patch" in
https://lists.gnu.org/archive/html/grub-devel/2023-03/msg00034.html

-
Code review:

When reviewing the patch code i skipped over the white space changes in
patch 2, trusting that the compilers would catch any typos which were
inserted by random mistake. (I.e. finger errors, not brain errors.)

The effective code changes look good to me.

---

My cheat sheet says that i shall prepare a branch, push it, and ask
for merging. So i did:

  $ git push --set-upstream origin pete_batard_ce_v3
  Enter passphrase for key '[censored]':
  Counting objects: 13, done.
  Delta compression using up to 8 threads.
  Compressing objects: 100% (13/13), done.
  Writing objects: 100% (13/13), 2.38 KiB | 0 bytes/s, done.
  Total 13 (delta 11), reused 0 (delta 0)
  To scdbac...@git.sv.gnu.org:/srv/git/libcdio.git
   * [new branch]  pete_batard_ce_v3 -> pete_batard_ce_v3
  Branch pete_batard_ce_v3 set up to track remote branch pete_batard_ce_v3 from 
origin.


Have a nice day :)

Thomas

Re: [Libcdio-devel] [PATCH] Fix gcc warnings

[Thomas Schmitt]

Hi,

the patch applies and compiles without complaints.

I was riddling about the exact meaning of "{ 0 }" when the struct has more
than one member. In Linux time.h struct tm is declared with 11 members.
Finally i found in C11 specs (ISO/IEC 9899:2011 6.7.9 21):
  If there are fewer initializers in a brace-enclosed list than there
  are elements or members of an aggregate, [...] the remainder of the
  aggregate shall be initialized implicitly the same as objects that have
  static storage duration.
And as we know from Kermighan & Ritchie, static variables are
automatically initialized to zero.

I lack of any test ideas for a mere initialization.

So i pushed the branch "pete_batard_gcc_warnings".
It is based on "master", not on the pending "pete_batard_ce_v3".

--

Rocky:
I never merged anything in git. If you expect me to merge on my own, then
please tell me the exact command which you would use for merging in
"pete_batard_gcc_warnings" and "pete_batard_ce_v3".
Actually i would prefer to have you as final doorman at "master".


Have a nice day :)

Thomas

Re: [Libcdio-devel] [PATCH] Fix gcc warnings

[Rocky Bernstein]

On Thu, Mar 23, 2023 at 3:12 PM Thomas Schmitt  wrote:

> Hi,
>
> the patch applies and compiles without complaints.
>
> I was riddling about the exact meaning of "{ 0 }" when the struct has more
> than one member. In Linux time.h struct tm is declared with 11 members.
> Finally i found in C11 specs (ISO/IEC 9899:2011 6.7.9 21):
>   If there are fewer initializers in a brace-enclosed list than there
>   are elements or members of an aggregate, [...] the remainder of the
>   aggregate shall be initialized implicitly the same as objects that have
>   static storage duration.
> And as we know from Kermighan & Ritchie, static variables are
> automatically initialized to zero.
>
> I lack of any test ideas for a mere initialization.
>
> So i pushed the branch "pete_batard_gcc_warnings".
> It is based on "master", not on the pending "pete_batard_ce_v3".
>
> --
>
> Rocky:
> I never merged anything in git. If you expect me to merge on my own, then
> please tell me the exact command which you would use for merging in
> "pete_batard_gcc_warnings" and "pete_batard_ce_v3".
> Actually i would prefer to have you as final doorman at "master".
>
>
> Have a nice day :)
>
> Thomas
>

I was thinking that Pete would do the merge since he also has commit rights
after the two of you  decide that it is time to merge

Pete knows which branch and so is the right one and so on. Of course,  I am
happy to help in whatever way I can or that makes sense.

Re: [Libcdio-devel] [PATCH] Fix gcc warnings

[Pete Batard via Libcdio-devel]

Actually I don't mind if you guys sort it out as last time I checked (a 
couple years ago), I had lost my ssh access right (which means that 
right now I'm just using https to clone the repo) and I'm a bit busy 
with other stuff ATM.


I'm actually quite happy to see that Thomas has take upon himself to 
create branches and carry additional testing to prepare for merging, so 
thanks for doing that.


Regards,

/Pete

On 2023.03.23 19:54, Rocky Bernstein wrote:



On Thu, Mar 23, 2023 at 3:12 PM Thomas Schmitt > wrote:


Hi,

the patch applies and compiles without complaints.

I was riddling about the exact meaning of "{ 0 }" when the struct
has more
than one member. In Linux time.h struct tm is declared with 11 members.
Finally i found in C11 specs (ISO/IEC 9899:2011 6.7.9 21):
   If there are fewer initializers in a brace-enclosed list than there
   are elements or members of an aggregate, [...] the remainder of the
   aggregate shall be initialized implicitly the same as objects
that have
   static storage duration.
And as we know from Kermighan & Ritchie, static variables are
automatically initialized to zero.

I lack of any test ideas for a mere initialization.

So i pushed the branch "pete_batard_gcc_warnings".
It is based on "master", not on the pending "pete_batard_ce_v3".

--

Rocky:
I never merged anything in git. If you expect me to merge on my own,
then
please tell me the exact command which you would use for merging in
"pete_batard_gcc_warnings" and "pete_batard_ce_v3".
Actually i would prefer to have you as final doorman at "master".


Have a nice day :)

Thomas


I was thinking that Pete would do the merge since he also has commit 
rights after the two of you  decide that it is time to merge


Pete knows which branch and so is the right one and so on. Of course,  I 
am happy to help in whatever way I can or that makes sense.

Re: [Libcdio-devel] [PATCH] Fix gcc warnings

[Rocky Bernstein]

Ok. Just give me the SHA1 of the code that you'd like to see in master and
I will test it as well. And assuming everything works and it looks like
what has been mentioned here, I will merge it and let everyone know.

On Thu, Mar 23, 2023 at 3:58 PM Pete Batard  wrote:

> Actually I don't mind if you guys sort it out as last time I checked (a
> couple years ago), I had lost my ssh access right (which means that
> right now I'm just using https to clone the repo) and I'm a bit busy
> with other stuff ATM.
>
> I'm actually quite happy to see that Thomas has take upon himself to
> create branches and carry additional testing to prepare for merging, so
> thanks for doing that.
>
> Regards,
>
> /Pete
>
> On 2023.03.23 19:54, Rocky Bernstein wrote:
> >
> >
> > On Thu, Mar 23, 2023 at 3:12 PM Thomas Schmitt  > > wrote:
> >
> > Hi,
> >
> > the patch applies and compiles without complaints.
> >
> > I was riddling about the exact meaning of "{ 0 }" when the struct
> > has more
> > than one member. In Linux time.h struct tm is declared with 11
> members.
> > Finally i found in C11 specs (ISO/IEC 9899:2011 6.7.9 21):
> >If there are fewer initializers in a brace-enclosed list than
> there
> >are elements or members of an aggregate, [...] the remainder of
> the
> >aggregate shall be initialized implicitly the same as objects
> > that have
> >static storage duration.
> > And as we know from Kermighan & Ritchie, static variables are
> > automatically initialized to zero.
> >
> > I lack of any test ideas for a mere initialization.
> >
> > So i pushed the branch "pete_batard_gcc_warnings".
> > It is based on "master", not on the pending "pete_batard_ce_v3".
> >
> >
>  --
> >
> > Rocky:
> > I never merged anything in git. If you expect me to merge on my own,
> > then
> > please tell me the exact command which you would use for merging in
> > "pete_batard_gcc_warnings" and "pete_batard_ce_v3".
> > Actually i would prefer to have you as final doorman at "master".
> >
> >
> > Have a nice day :)
> >
> > Thomas
> >
> >
> > I was thinking that Pete would do the merge since he also has commit
> > rights after the two of you  decide that it is time to merge
> >
> > Pete knows which branch and so is the right one and so on. Of course,  I
> > am happy to help in whatever way I can or that makes sense.
> >
> >
>
>

Re: [Libcdio-devel] [PATCH] Fix gcc warnings

[Pete Batard via Libcdio-devel]

I guess that would be fdd76a8ee4f4f00f1eabc6f632322db800ee9970 from the 
pete_batard_ce_v3 branch. And then there's the one patch from 
pete_batard_ce_v3 with SHA 569c452f8d1650c0ec50ebeef7869b54ed9c8be6.


Thanks!

/Pete

On 2023.03.23 20:03, Rocky Bernstein wrote:
Ok. Just give me the SHA1 of the code that you'd like to see in master 
and I will test it as well. And assuming everything works and it looks 
like what has been mentioned here, I will merge it and let everyone know.


On Thu, Mar 23, 2023 at 3:58 PM Pete Batard > wrote:


Actually I don't mind if you guys sort it out as last time I checked (a
couple years ago), I had lost my ssh access right (which means that
right now I'm just using https to clone the repo) and I'm a bit busy
with other stuff ATM.

I'm actually quite happy to see that Thomas has take upon himself to
create branches and carry additional testing to prepare for merging, so
thanks for doing that.

Regards,

/Pete

On 2023.03.23 19:54, Rocky Bernstein wrote:
 >
 >
 > On Thu, Mar 23, 2023 at 3:12 PM Thomas Schmitt mailto:scdbac...@gmx.net>
 > >> wrote:
 >
 >     Hi,
 >
 >     the patch applies and compiles without complaints.
 >
 >     I was riddling about the exact meaning of "{ 0 }" when the struct
 >     has more
 >     than one member. In Linux time.h struct tm is declared with
11 members.
 >     Finally i found in C11 specs (ISO/IEC 9899:2011 6.7.9 21):
 >        If there are fewer initializers in a brace-enclosed list
than there
 >        are elements or members of an aggregate, [...] the
remainder of the
 >        aggregate shall be initialized implicitly the same as objects
 >     that have
 >        static storage duration.
 >     And as we know from Kermighan & Ritchie, static variables are
 >     automatically initialized to zero.
 >
 >     I lack of any test ideas for a mere initialization.
 >
 >     So i pushed the branch "pete_batard_gcc_warnings".
 >     It is based on "master", not on the pending "pete_batard_ce_v3".
 >
 >   
  --

 >
 >     Rocky:
 >     I never merged anything in git. If you expect me to merge on
my own,
 >     then
 >     please tell me the exact command which you would use for
merging in
 >     "pete_batard_gcc_warnings" and "pete_batard_ce_v3".
 >     Actually i would prefer to have you as final doorman at "master".
 >
 >
 >     Have a nice day :)
 >
 >     Thomas
 >
 >
 > I was thinking that Pete would do the merge since he also has commit
 > rights after the two of you  decide that it is time to merge
 >
 > Pete knows which branch and so is the right one and so on. Of
course,  I
 > am happy to help in whatever way I can or that makes sense.
 >
 >

Re: [Libcdio-devel] [PATCH] Fix gcc warnings

[Rocky Bernstein]

And for clarity use git show to get the SHA1. I just pulled master and here
is what I currently see:

$ git show
commit 6f2426e8bf4dc5269ccbd9fbfa94340895f8be6e (HEAD -> master,
origin/master, origin/HEAD)
Author: Robert Kausch 
Date:   Wed Mar 15 00:02:10 2023 +0100

Fix crash reading CD TOC on macOS Ventura

Remove unnecessary additional byte added to the TOC buffer length and
length of the range requested from CFDataGetBytes. As of macOS Ventura,
CFDataGetBytes checks the requested length and asserts if more data than
available is requested.

diff --git a/lib/driver/osx.c b/lib/driver/osx.c
index d48b5a0e..af2fe402 100644
...

And clearly this does not seem current.

569c452f8d1650c0ec50ebeef7869b54ed9c8be6 (pete_batard_gcc_warnings)  and
fdd76a8ee4f4f00f1eabc6f632322db800ee9970 (Add processing of Rock Ridge CE
records)

are the two likely candidates as Thomas has said.

Pete, and Thomas - which of these goes to master?



On Thu, Mar 23, 2023 at 4:03 PM Rocky Bernstein  wrote:

> Ok. Just give me the SHA1 of the code that you'd like to see in master and
> I will test it as well. And assuming everything works and it looks like
> what has been mentioned here, I will merge it and let everyone know.
>
> On Thu, Mar 23, 2023 at 3:58 PM Pete Batard  wrote:
>
>> Actually I don't mind if you guys sort it out as last time I checked (a
>> couple years ago), I had lost my ssh access right (which means that
>> right now I'm just using https to clone the repo) and I'm a bit busy
>> with other stuff ATM.
>>
>> I'm actually quite happy to see that Thomas has take upon himself to
>> create branches and carry additional testing to prepare for merging, so
>> thanks for doing that.
>>
>> Regards,
>>
>> /Pete
>>
>> On 2023.03.23 19:54, Rocky Bernstein wrote:
>> >
>> >
>> > On Thu, Mar 23, 2023 at 3:12 PM Thomas Schmitt > > > wrote:
>> >
>> > Hi,
>> >
>> > the patch applies and compiles without complaints.
>> >
>> > I was riddling about the exact meaning of "{ 0 }" when the struct
>> > has more
>> > than one member. In Linux time.h struct tm is declared with 11
>> members.
>> > Finally i found in C11 specs (ISO/IEC 9899:2011 6.7.9 21):
>> >If there are fewer initializers in a brace-enclosed list than
>> there
>> >are elements or members of an aggregate, [...] the remainder of
>> the
>> >aggregate shall be initialized implicitly the same as objects
>> > that have
>> >static storage duration.
>> > And as we know from Kermighan & Ritchie, static variables are
>> > automatically initialized to zero.
>> >
>> > I lack of any test ideas for a mere initialization.
>> >
>> > So i pushed the branch "pete_batard_gcc_warnings".
>> > It is based on "master", not on the pending "pete_batard_ce_v3".
>> >
>> >
>>  --
>> >
>> > Rocky:
>> > I never merged anything in git. If you expect me to merge on my own,
>> > then
>> > please tell me the exact command which you would use for merging in
>> > "pete_batard_gcc_warnings" and "pete_batard_ce_v3".
>> > Actually i would prefer to have you as final doorman at "master".
>> >
>> >
>> > Have a nice day :)
>> >
>> > Thomas
>> >
>> >
>> > I was thinking that Pete would do the merge since he also has commit
>> > rights after the two of you  decide that it is time to merge
>> >
>> > Pete knows which branch and so is the right one and so on. Of course,
>> I
>> > am happy to help in whatever way I can or that makes sense.
>> >
>> >
>>
>>

Re: [Libcdio-devel] [PATCH] Fix gcc warnings

[Rocky Bernstein]

Ok got it - thanks!

I will have to do this a bit later though because I want to be careful and
test everything and I cannot do that right now.

On Thu, Mar 23, 2023 at 4:10 PM Pete Batard  wrote:

> I guess that would be fdd76a8ee4f4f00f1eabc6f632322db800ee9970 from the
> pete_batard_ce_v3 branch. And then there's the one patch from
> pete_batard_ce_v3 with SHA 569c452f8d1650c0ec50ebeef7869b54ed9c8be6.
>
> Thanks!
>
> /Pete
>
> On 2023.03.23 20:03, Rocky Bernstein wrote:
> > Ok. Just give me the SHA1 of the code that you'd like to see in master
> > and I will test it as well. And assuming everything works and it looks
> > like what has been mentioned here, I will merge it and let everyone know.
> >
> > On Thu, Mar 23, 2023 at 3:58 PM Pete Batard  > > wrote:
> >
> > Actually I don't mind if you guys sort it out as last time I checked
> (a
> > couple years ago), I had lost my ssh access right (which means that
> > right now I'm just using https to clone the repo) and I'm a bit busy
> > with other stuff ATM.
> >
> > I'm actually quite happy to see that Thomas has take upon himself to
> > create branches and carry additional testing to prepare for merging,
> so
> > thanks for doing that.
> >
> > Regards,
> >
> > /Pete
> >
> > On 2023.03.23 19:54, Rocky Bernstein wrote:
> >  >
> >  >
> >  > On Thu, Mar 23, 2023 at 3:12 PM Thomas Schmitt  > 
> >  > >> wrote:
> >  >
> >  > Hi,
> >  >
> >  > the patch applies and compiles without complaints.
> >  >
> >  > I was riddling about the exact meaning of "{ 0 }" when the
> struct
> >  > has more
> >  > than one member. In Linux time.h struct tm is declared with
> > 11 members.
> >  > Finally i found in C11 specs (ISO/IEC 9899:2011 6.7.9 21):
> >  >If there are fewer initializers in a brace-enclosed list
> > than there
> >  >are elements or members of an aggregate, [...] the
> > remainder of the
> >  >aggregate shall be initialized implicitly the same as
> objects
> >  > that have
> >  >static storage duration.
> >  > And as we know from Kermighan & Ritchie, static variables are
> >  > automatically initialized to zero.
> >  >
> >  > I lack of any test ideas for a mere initialization.
> >  >
> >  > So i pushed the branch "pete_batard_gcc_warnings".
> >  > It is based on "master", not on the pending
> "pete_batard_ce_v3".
> >  >
> >  >
> >
>  --
> >  >
> >  > Rocky:
> >  > I never merged anything in git. If you expect me to merge on
> > my own,
> >  > then
> >  > please tell me the exact command which you would use for
> > merging in
> >  > "pete_batard_gcc_warnings" and "pete_batard_ce_v3".
> >  > Actually i would prefer to have you as final doorman at
> "master".
> >  >
> >  >
> >  > Have a nice day :)
> >  >
> >  > Thomas
> >  >
> >  >
> >  > I was thinking that Pete would do the merge since he also has
> commit
> >  > rights after the two of you  decide that it is time to merge
> >  >
> >  > Pete knows which branch and so is the right one and so on. Of
> > course,  I
> >  > am happy to help in whatever way I can or that makes sense.
> >  >
> >  >
> >
>
>

Re: [Libcdio-devel] [PATCH] Fix gcc warnings

[Thomas Schmitt]

Hi,

Rocky Bernstein wrote:
> I was thinking that Pete would do the merge since he also has commit rights
> after the two of you  decide that it is time to merge

Everybody is more qualified as git admin than i am.


Pete Batard wrote:
> Actually I don't mind if you guys sort it out as last time I checked (a
> couple years ago), I had lost my ssh access right (which means that right
> now I'm just using https to clone the repo) and I'm a bit busy with other
> stuff ATM.

This explains why you sent patches instead of preparing branches.

So somebody must tell me what to do exactly for merging.
(I read man git-merge but would prefer to succeed on the first try.)


Rocky Bernstein wrote:
> Ok. Just give me the SHA1 of the code that you'd like to see in master and
> I will test it as well. And assuming everything works and it looks like
> what has been mentioned here, I will merge it and let everyone know.

Or that way. :))

The two branches "pete_batard_ce_v3" and "pete_batard_gcc_warnings"
differ from "master" only by the three patches from Pete.
pete_batard_ce_v3:
  commit 7896babce4a3fe3f27e733e4df3727f1e917bfd6
  "Clean up rock.h and fix the use of char arrays in iso_su_ce_s"
  commit fdd76a8ee4f4f00f1eabc6f632322db800ee9970
  "Add processing of Rock Ridge CE records"
pete_batard_gcc_warnings:
  commit 569c452f8d1650c0ec50ebeef7869b54ed9c8be6
  "Fix gcc warnings"
Taken from git log of each branch.


Next i will try to find out what's up with "joliet_multi_extent".


Have a nice day :)

Thomas

Re: [Libcdio-devel] [PATCH] Fix gcc warnings

[Rocky Bernstein]

On Thu, Mar 23, 2023 at 5:13 PM Thomas Schmitt  wrote:

> Hi,
>
> Rocky Bernstein wrote:
> > I was thinking that Pete would do the merge since he also has commit
> rights
> > after the two of you  decide that it is time to merge
>
> Everybody is more qualified as git admin than i am.
>
>
> Pete Batard wrote:
> > Actually I don't mind if you guys sort it out as last time I checked (a
> > couple years ago), I had lost my ssh access right (which means that right
> > now I'm just using https to clone the repo) and I'm a bit busy with other
> > stuff ATM.
>
> This explains why you sent patches instead of preparing branches.
>
> So somebody must tell me what to do exactly for merging.
> (I read man git-merge but would prefer to succeed on the first try.)
>

Here  is an command-line example of what might be done:

$ cd libcdio  # or wherever you have libcdio checked out
$ git checkout master
Already on 'master'
Your branch is up to date with 'origin/master'.
$ git pull
Already up to date.
$ git merge fdd76a8ee4f4f00f1eabc6f632322db800ee9970
Updating 6f2426e8..fdd76a8e
Fast-forward
 include/cdio/rock.h | 20 ++--
 lib/iso9660/rock.c  | 98
+-
 2 files changed, 71 insertions(+), 47 deletions(-)
$ # Run some tests and check over the Rockridge patches
$ git merge 569c452f8d1650c0ec50ebeef7869b54ed9c8be6
hint: Waiting for your editor to close the file...
Waiting for Emacs...
# Here I was put in $EDITOR (GNU Emacs) and I entered the comment:
# Explicit initialization of tm_temp_tmp
Merge made by the 'ort' strategy.
 lib/iso9660/iso9660.c | 2 +-

# Do more tests here

$ git status
On branch master
Your branch is ahead of 'origin/master' by 4 commits.
  (use "git push" to publish your local commits)

$ # The below is the last step which I have not done...
$ # git push

Thomas - I encourage you to do the same, but do the tests and checks at the
appropriate places.

There is no way you can mess up in git, because history is saved by default
for *everyone. *And specifically I have a copy.

And if you want to set up a video conference or chat I am also happy to
look over your shoulder and explain anything that might be a mystery.

In other words, this is supposed to be a stress on you, we want you to
succeed.

But on the other hand if you want me to do this, I am also okay with that.
But I will redo with the missing testing steps,
which I am not as proficient at. Here - either of you are probably better
than  :-)


>
>
> Rocky Bernstein wrote:
> > Ok. Just give me the SHA1 of the code that you'd like to see in master
> and
> > I will test it as well. And assuming everything works and it looks like
> > what has been mentioned here, I will merge it and let everyone know.
>
> Or that way. :))
>
> The two branches "pete_batard_ce_v3" and "pete_batard_gcc_warnings"
> differ from "master" only by the three patches from Pete.
> pete_batard_ce_v3:
>   commit 7896babce4a3fe3f27e733e4df3727f1e917bfd6
>   "Clean up rock.h and fix the use of char arrays in iso_su_ce_s"
>   commit fdd76a8ee4f4f00f1eabc6f632322db800ee9970
>   "Add processing of Rock Ridge CE records"
> pete_batard_gcc_warnings:
>   commit 569c452f8d1650c0ec50ebeef7869b54ed9c8be6
>   "Fix gcc warnings"
> Taken from git log of each branch.


>
> Next i will try to find out what's up with "joliet_multi_extent".
>
>
> Have a nice day :)
>
> Thomas
>
>
>

[Libcdio-devel] CD-Text support for macOS and Windows

[Robert Kausch via Libcdio-devel]

Hi all,

It's been a long time since I've been active here and it's time to 
contribute some patches again...


I just pushed the cdtext-osx and cdtext-win32 branches which add/improve 
support for reading CD-Text on those systems. The win32 branch also has 
patches for the Windows-specific text conversion functions to fix UTF-8 
to UCS-2 conversion and add support for converting ISO-8859-1 and Shift 
JIS to UTF-8, needed for proper CD-Text support.


If there are no objections, I'd like to merge these to master after a 
few days.


The macOS code has been in use in the macOS version of fre:ac for the 
past 3 years already, so I'd consider it well tested. The Windows code, 
however, I only tested myself when I initially developed it, so if 
someone else could give it a try, that would be great.


By the way, I already committed a fix for a crash affecting macOS 
Ventura last week. Sorry for not announcing it on the mailing list first.


Best,
Robert

--

Robert Kausch
robert.kau...@freac.org