Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming

[Pete Batard]

On 2012.03.06 04:13, Rocky Bernstein wrote:
> All your changes are now merged into master.

Great! Many thanks.
Will try to follow with the MSVC changes now, but I want to add DLL 
support with a project sample, since it'll probably be one of the most 
requested feature for Windows otherwise, and additional work is required 
for that than what is currently present in -pbatard.

> > Note that I tested quite a few bootable ISO9660 images with Joliet, since
> > I'm dealing with these a lot in my app.
>
> I regret that the problems and fixes that you encounter are currently
> mostly known and reproducible by you. That generally means that sometime in
> the future someone somewhere (read: me) will break things. Sure, I
> understand it is *work* to isolate problems into small reproducible test
> cases, but I also subscribe to the view that  programming, development and
> testing can be incremental.

When either one has time or is paid (to have the time) for it, I would say.
Else, the #1 priority remains making the software work and until that 
has been achieved, ad-hoc testing should be acceptable. This is 
especially true for a FOSS project, as one may leverage the old: "With 
enough eyeballs all bugs become shallow".

If we can increase the number of people who look at the code, by trying 
to get the libcdio ball rolling on Windows, then not having a set of 
test that is as comprehensive as we can make it may not be that big a 
deal. Especially, the concern has also to be with bugs that have yet to 
be identified, and that only someone testing in a specific set of 
conditions, that we wouldn't devise a test for, would bring into light. 
A lot of the issues I picked up aren't ones I would immediately have 
though to produce a test for...

> So if there are images that libcdio had problems, a simple, low-tech thing
> to do is jot down in a file somewhere the image and its characteristics and
> what is expected. Even if this is a text file rather than code, it means
> someone has a hope in the future to try to go further.

Then I'm not sure if this is that far from my original plan, which was 
to just provide a list of publicly available ISOs, that libcdio seemed 
to have an issue with, as well as a description of the issue encountered 
and how to test it. For instance, trying to produce an UDF with at least 
one 4 GB file, in order to check that LFS support is working properly, 
is expected to be more time consuming than simply issuing a wget of a 
public ISO...

> To further suggest the usefulness of this approach, consider that TODO item
> you reported on above. It is possible that if I hadn't written that, you
> might not have considered implementing it.

I'm grateful for the TODO. I may have figured it out, but it'd 
definitely have taken me a lot longer to do so, so that was indeed great 
help.

> > Next are Windows related fixes to enable stat()/fopen() of UTF-8 paths.
> > Unlike UNIX, Microsoft took the very insane decision of not making existing
> > char* calls UTF-8 compatibles, but instead force all Windows developers to
> > go through cumbersome wchar_t strings whenever Unicode is required, which
> > of course prevents the opening of streams that contain extended characters.
> > This commit addresses that and was also validated, at least for the opening
> > of ISO images, in my app.
>
> Again, I'd suggest jotting down in a file somewhere we can distribute with
> libcdio such an example image that one might be able to easily obtain.

In this case, the problem was not with the ISO itself but the path to 
the ISO (eg: c:/<some_dir_with_Japanese_characters>/some.iso), which 
wouldn't fail on most UTF-8 POSIX compliant platforms, but will on Windows.

Note that extract.c is not Unicode compliant on Windows either, because 
of the same limitation, but I'm not planning to fix that. This is 
because there is no good portable fix for that as it ultimately requires 
something like:

#ifdef _WIN32
 wpath = convert_to_wchar(path);
 HANDLE h = CreateFileW(wpath, ...)
 free(wpath);
#else
 fd = fopen(path, ...)
#endif
 ...
#ifdef _WIN32
 WriteFile(h, ...);
#else
  fwrite(fd, ....);
#endif

I think it's probably best to keep the sample simple instead.

> > The one item I still have open for MinGW is the rockridge test: If you
> > configure libcdio with --enable-rock, the rockridge test fails with the
> > following:
>
> A simple thing to do is to skip this test on MinGW

Yeah. I'll try to add that workaround.

Regards,

/Pete