[libbluray-devel] [PATCH 2/4] The number of bytes used by fixed-length character fields is stored as Uint8 (ECMA 1/7.2.12).

[Andreas Zelend]

2017-06-01 9:49 GMT+02:00 Petri Hintukainen <phintuka at users.sourceforge.net>
:

> ke, 2017-05-31 kello 12:33 +0200, Andreas Zelend kirjoitti:
> >
> > 2017-05-31 10:29 GMT+02:00 Petri Hintukainen <phintuka at users.sourcefo
> > rge.net>:
> > > I didn't find any limitation for field length. Recorded string
> > > length
> > > is limited to 255 (because of it is stored in Uint8).
> > > This would mean field length can be 256 (or even more if there's
> > > padding) ?
> > >
> >
> > That's right, the caller has to make sure that he uses the correct
> > field length.
>
> Field lengths are constants from specifications. Currently this is not
> an issue, it just feels safer to write code that can handle all
> possible values.
>
> > I'll prepare another patch regarding off_t size problems.
>
> in libudfread ?
>
> off_t is used in only one file, maybe you can just define it to
> uint64_t or something else. Or add native Windows API versions of the
> remaining functions.
>
> Yes, maybe the following:

>From 6ba9f18fbb4cfa9994a7c33d30750d30daff2fc4 Mon Sep 17 00:00:00 2001
From: ace20022 <ace20022 at ymail.com>
Date: Thu, 14 Jan 2016 15:46:43 +0100
Subject: [PATCH] Use 64-bit version of lseek and off_t for win32.

---
 src/default_blockinput.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/src/default_blockinput.c b/src/default_blockinput.c
index 4daa6a3..aaa8c62 100644
--- a/src/default_blockinput.c
+++ b/src/default_blockinput.c
@@ -41,6 +41,10 @@
 #include <stdio.h>
 #endif
 #include <io.h>
+# undef  lseek
+# define lseek _lseeki64
+# undef  off_t
+# define off_t int64_t
 #endif

 #ifdef __ANDROID__
-- 
2.12.0.windows.1

I've only tested it with msvc, not with mingw. The issue that needs fixing
is the right shift at line 67 ov.OffsetHigh = (offset >> 32);
which is undefined (nop in my case) if offset is a 32-bit variable.



> > btw do you plan to tag a release in the near future?
>
> libudfread ?
> We could tag 1.0.0, there haven't been much changes recently.
>

> libbluray ?
> Probably sooner than later, there's already a pile of fixes since
> previous release.
>
> I've found a crash yesterday when calling bd_get_event between bd_init and
bd_open* , since bd->disc is null. Are you interested?

Having a new release for both libs would be great.



> > _______________________________________________
> > libbluray-devel mailing list
> > libbluray-devel at videolan.org
> > https://mailman.videolan.org/listinfo/libbluray-devel
> _______________________________________________
> libbluray-devel mailing list
> libbluray-devel at videolan.org
> https://mailman.videolan.org/listinfo/libbluray-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/libbluray-devel/attachments/20170602/d8ab903c/attachment.html>