[DVDnav-discuss] libdvdnav vs. libdvdnav2

[Nico Sabbi]

Jean-Baptiste Kempf wrote:
> 
> Just to say, that VLC team is around, and we are watching very closely.
> 
> We have a few patches against libdvdnav and some have been commited in a
> way or another. 
> 
> However, I haven't checked yet (a bit overloaded those days) if our main 
> patch on dvdnav can be removed, and it be found here, if needed:
> http://trac.videolan.org/vlc/browser/trunk/extras/contrib/src/Patches/dvdnav.patch
> If you need any info on our building process, just ask :D
> 

I gave it a look and applied a couple of small patches, but I found 
something unconvincing in that link:

** in dvd_reader.c:
368	366	    /* First check if this is a block/char device or a file*/
369	 	    if( S_ISBLK( fileinfo.st_mode ) ||
  	367	    if( !*path || S_ISBLK( fileinfo.st_mode ) ||
370	368	        S_ISCHR( fileinfo.st_mode ) ||
371	369	        S_ISREG( fileinfo.st_mode ) ) {

why if !*path  (i.e. when path is an empty string) we should treat it 
as if it were a block device?

** in bswap.h:
- 0xff00000000000000
+ 0xff00000000000000LL seems nonsense to me: in C integer numbers are 
automatically enclosed in the smallest enclosing type, that for a 
64bit value like that can only be a 64 bit value (in both 32 and 64 
bit architectures).
I see that there are also smaller values such as 0x00000000ff000000,
but still...

** in vm.c:
in dvd_read_name() fd is transformed to dvd_input_t
and open() is replaced with dvdinput_open(), but dvdinput_t
(the type returned by dvdinput_open()) is a struct, not an int.
Can you explain, please?

** I prefer to delay the beos<->css code alone to a better moment.

Overall the differences are mininal; can you try linking vlc with this 
fork when you have some time, please?

Thanks,
	Nico