[PATCH] do not close file twice
There is another close further down that will always be reached. Current code will result in a double close. Index: vm/vm.c =================================================================== --- vm/vm.c (revision 1243) +++ vm/vm.c (working copy) @@ -176,7 +176,6 @@ off = lseek( fd, 32 * (off_t) DVD_VIDEO_LB_LEN, SEEK_SET ); if( off == ( 32 * (off_t) DVD_VIDEO_LB_LEN ) ) { off = read( fd, data, DVD_VIDEO_LB_LEN ); - close(fd); if (off == ( (off_t) DVD_VIDEO_LB_LEN )) { fprintf(MSG_OUT, "libdvdnav: DVD Title: "); for(i=25; i < 73; i++ ) {
Also dealt w/ in the commit in November '11 in my github tree: https://github.com/microe/libdvdnav Thanks E On Tue, Nov 6, 2012 at 10:25 AM, Reimar Döffinger <Reimar.Doeffinger@gmx.de> wrote:
There is another close further down that will always be reached. Current code will result in a double close.
Index: vm/vm.c =================================================================== --- vm/vm.c (revision 1243) +++ vm/vm.c (working copy) @@ -176,7 +176,6 @@ off = lseek( fd, 32 * (off_t) DVD_VIDEO_LB_LEN, SEEK_SET ); if( off == ( 32 * (off_t) DVD_VIDEO_LB_LEN ) ) { off = read( fd, data, DVD_VIDEO_LB_LEN ); - close(fd); if (off == ( (off_t) DVD_VIDEO_LB_LEN )) { fprintf(MSG_OUT, "libdvdnav: DVD Title: "); for(i=25; i < 73; i++ ) {
_______________________________________________ DVDnav-discuss mailing list DVDnav-discuss@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/dvdnav-discuss
-- Erik Hovland erik@hovland.org http://hovland.org/
On 06 Nov, Erik Hovland wrote :
Also dealt w/ in the commit in November '11 in my github tree: https://github.com/microe/libdvdnav
When is your tree going to be the reference? Because, seriously, this is über-annoying... Best regards, -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device
On Tue, Nov 6, 2012 at 11:10 AM, Jean-Baptiste Kempf <jb@videolan.org> wrote:
On 06 Nov, Erik Hovland wrote :
Also dealt w/ in the commit in November '11 in my github tree: https://github.com/microe/libdvdnav
When is your tree going to be the reference?
Probably never.
Because, seriously, this is über-annoying...
I will strive to make using mplayerhq svn less annoying. E -- Erik Hovland erik@hovland.org http://hovland.org/
On 06 Nov, Erik Hovland wrote :
Because, seriously, this is über-annoying... I will strive to make using mplayerhq svn less annoying.
The issue is not using svn vs git or whatever. The issue is that libdvdnav crashes a lot and your tree makes is a bit less bad... Best regards, -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device
On Tue, Nov 6, 2012 at 11:34 AM, Jean-Baptiste Kempf <jb@videolan.org> wrote:
On 06 Nov, Erik Hovland wrote :
Because, seriously, this is über-annoying... I will strive to make using mplayerhq svn less annoying.
The issue is not using svn vs git or whatever. The issue is that libdvdnav crashes a lot and your tree makes is a bit less bad...
OK, then I strive to make the mplayerhq repository also be a bit less bad. Thanks E -- Erik Hovland erik@hovland.org http://hovland.org/
On Tue, Nov 06, 2012 at 10:43:14AM -0800, Erik Hovland wrote:
Also dealt w/ in the commit in November '11 in my github tree: https://github.com/microe/libdvdnav
What's the point in hoarding such trivial patches for almost a year in a repository nobody knows about (it sure isn't on the homepage)? I see that larger patches might needs some testing or longer work on them, but that is hardly what I'd consider a good use of private/development repositories.
On Tue, Nov 6, 2012 at 11:11 AM, Reimar Döffinger <Reimar.Doeffinger@gmx.de> wrote:
On Tue, Nov 06, 2012 at 10:43:14AM -0800, Erik Hovland wrote:
Also dealt w/ in the commit in November '11 in my github tree: https://github.com/microe/libdvdnav
What's the point in hoarding such trivial patches for almost a year in a repository nobody knows about (it sure isn't on the homepage)? I see that larger patches might needs some testing or longer work on them, but that is hardly what I'd consider a good use of private/development repositories.
There is no point in hoarding. The only reason most of these patches have not been committed is b/c of general laziness on my part. I still consider mplayerhq svn to be the canonical place for all libdvdread and libdvdnav development. So I *pinky-swear* promise to get my tree pushed into that repository as fast as I can. Is it too difficult to try my tree in the meantime? Thanks E -- Erik Hovland erik@hovland.org http://hovland.org/
On Tue, Nov 06, 2012 at 11:22:26AM -0800, Erik Hovland wrote:
On Tue, Nov 6, 2012 at 11:11 AM, Reimar Döffinger <Reimar.Doeffinger@gmx.de> wrote:
On Tue, Nov 06, 2012 at 10:43:14AM -0800, Erik Hovland wrote:
Also dealt w/ in the commit in November '11 in my github tree: https://github.com/microe/libdvdnav
What's the point in hoarding such trivial patches for almost a year in a repository nobody knows about (it sure isn't on the homepage)? I see that larger patches might needs some testing or longer work on them, but that is hardly what I'd consider a good use of private/development repositories.
There is no point in hoarding. The only reason most of these patches have not been committed is b/c of general laziness on my part.
I still consider mplayerhq svn to be the canonical place for all libdvdread and libdvdnav development. So I *pinky-swear* promise to get my tree pushed into that repository as fast as I can.
Is it too difficult to try my tree in the meantime?
Fairly, the thing I am "trying" is fixing MPlayer's Coverity scan results, integrating your tree is a bit annoying though if you're really interested I can give it a try.
On Tue, Nov 6, 2012 at 11:28 AM, Reimar Döffinger <Reimar.Doeffinger@gmx.de> wrote:
On Tue, Nov 06, 2012 at 11:22:26AM -0800, Erik Hovland wrote:
On Tue, Nov 6, 2012 at 11:11 AM, Reimar Döffinger <Reimar.Doeffinger@gmx.de> wrote:
On Tue, Nov 06, 2012 at 10:43:14AM -0800, Erik Hovland wrote:
Also dealt w/ in the commit in November '11 in my github tree: https://github.com/microe/libdvdnav
What's the point in hoarding such trivial patches for almost a year in a repository nobody knows about (it sure isn't on the homepage)? I see that larger patches might needs some testing or longer work on them, but that is hardly what I'd consider a good use of private/development repositories.
There is no point in hoarding. The only reason most of these patches have not been committed is b/c of general laziness on my part.
I still consider mplayerhq svn to be the canonical place for all libdvdread and libdvdnav development. So I *pinky-swear* promise to get my tree pushed into that repository as fast as I can.
Is it too difficult to try my tree in the meantime?
Fairly, the thing I am "trying" is fixing MPlayer's Coverity scan results, integrating your tree is a bit annoying though if you're really interested I can give it a try.
Ah, this makes sense. There are a lot of commits to my repo that address several coverity defects. Is there a way to get access to the MPlayer scan results? E -- Erik Hovland erik@hovland.org http://hovland.org/
On Tue, Nov 06, 2012 at 11:56:43AM -0800, Erik Hovland wrote:
On Tue, Nov 6, 2012 at 11:28 AM, Reimar Döffinger <Reimar.Doeffinger@gmx.de> wrote:
On Tue, Nov 06, 2012 at 11:22:26AM -0800, Erik Hovland wrote:
On Tue, Nov 6, 2012 at 11:11 AM, Reimar Döffinger <Reimar.Doeffinger@gmx.de> wrote:
On Tue, Nov 06, 2012 at 10:43:14AM -0800, Erik Hovland wrote:
Also dealt w/ in the commit in November '11 in my github tree: https://github.com/microe/libdvdnav
What's the point in hoarding such trivial patches for almost a year in a repository nobody knows about (it sure isn't on the homepage)? I see that larger patches might needs some testing or longer work on them, but that is hardly what I'd consider a good use of private/development repositories.
There is no point in hoarding. The only reason most of these patches have not been committed is b/c of general laziness on my part.
I still consider mplayerhq svn to be the canonical place for all libdvdread and libdvdnav development. So I *pinky-swear* promise to get my tree pushed into that repository as fast as I can.
Is it too difficult to try my tree in the meantime?
Fairly, the thing I am "trying" is fixing MPlayer's Coverity scan results, integrating your tree is a bit annoying though if you're really interested I can give it a try.
Ah, this makes sense. There are a lot of commits to my repo that address several coverity defects.
Is there a way to get access to the MPlayer scan results?
Yes, ask me for access. (+ tell me which email address I should give to them). Obviously you could of course try applying for your own project account for libdvd*, see e.g. http://scan.coverity.com/developers-faq.html However to upload a scan you need to have a way to get all code that you want analyzed compiled in one go.
On Tue, Nov 06, 2012 at 11:56:43AM -0800, Erik Hovland wrote:
On Tue, Nov 6, 2012 at 11:28 AM, Reimar Döffinger <Reimar.Doeffinger@gmx.de> wrote:
On Tue, Nov 06, 2012 at 11:22:26AM -0800, Erik Hovland wrote:
On Tue, Nov 6, 2012 at 11:11 AM, Reimar Döffinger <Reimar.Doeffinger@gmx.de> wrote:
On Tue, Nov 06, 2012 at 10:43:14AM -0800, Erik Hovland wrote:
Also dealt w/ in the commit in November '11 in my github tree: https://github.com/microe/libdvdnav
What's the point in hoarding such trivial patches for almost a year in a repository nobody knows about (it sure isn't on the homepage)? I see that larger patches might needs some testing or longer work on them, but that is hardly what I'd consider a good use of private/development repositories.
There is no point in hoarding. The only reason most of these patches have not been committed is b/c of general laziness on my part.
I still consider mplayerhq svn to be the canonical place for all libdvdread and libdvdnav development. So I *pinky-swear* promise to get my tree pushed into that repository as fast as I can.
Is it too difficult to try my tree in the meantime?
Fairly, the thing I am "trying" is fixing MPlayer's Coverity scan results, integrating your tree is a bit annoying though if you're really interested I can give it a try.
Ah, this makes sense. There are a lot of commits to my repo that address several coverity defects.
None remain with code from your repository.
On Tue, Nov 06, 2012 at 11:22:26AM -0800, Erik Hovland wrote:
On Tue, Nov 6, 2012 at 11:11 AM, Reimar D?ffinger <Reimar.Doeffinger@gmx.de> wrote:
On Tue, Nov 06, 2012 at 10:43:14AM -0800, Erik Hovland wrote:
Also dealt w/ in the commit in November '11 in my github tree: https://github.com/microe/libdvdnav
What's the point in hoarding such trivial patches for almost a year in a repository nobody knows about (it sure isn't on the homepage)? I see that larger patches might needs some testing or longer work on them, but that is hardly what I'd consider a good use of private/development repositories.
There is no point in hoarding. The only reason most of these patches have not been committed is b/c of general laziness on my part.
I still consider mplayerhq svn to be the canonical place for all libdvdread and libdvdnav development. So I *pinky-swear* promise to get my tree pushed into that repository as fast as I can.
Is it too difficult to try my tree in the meantime?
Although I have back ported everything in your tree over top of 4.2.0 for OpenBSD it would be nice to get everything into the mplayerhq tree and roll a new release so that everyone benefits from the fixes. As it is most OS's will not receive these fixes as they're sitting in a git repo the port/package maintainers do not and should not have to know about. Same goes for libdvdread. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Tuesday, 06 November 2012 at 19:25, Reimar Döffinger wrote:
There is another close further down that will always be reached. Current code will result in a double close.
Applied to SVN. Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
participants (5)
-
Brad Smith -
Dominik 'Rathann' Mierzejewski -
Erik Hovland -
Jean-Baptiste Kempf -
Reimar Döffinger