[Matroska-devel] [Patches] Portability, support for CloudABI, etc.

Moritz Bunkus moritz at bunkus.org
Wed Nov 18 18:28:25 CET 2015


Hey,

thanks for the contribution.

> 1. Determinism

I get the requirement for determinism but removing the variable causes
an ABI break, and I'm not really willing to go there just for the sake
of determinism.

I would be OK with a configure option for that, though. Now that both
libraries use autoconf this should be easy enough to implement. Problem
is that a config.h that would define the appropriate preprocessor
#defines would have to be shipped and included somehow, too, making the
#requirement for a patch a bit larger.

If you're willing to invest the work to create a patch for the following
points then I'll apply it:

1. add option to configure, e.g. --without-build-timestamp
2. patch both the header and source files to exclude the variable
   depending on the configure option
3. rename config.h to something else (e.g. libebml_config.h), patch a
   central include file (e.g. EbmlConfig.h) to include libebml_config.h,
   and patch the Makefile.am to install the file upon "make install"

It would be enough for libEBML; I could adjust it for libMatroska.

A less invasive approach might be to keep the variable but to leave it
empty.

> 2. Missing include of <stdlib.h>

That's fine, of course, I'll use it.

> 3. Use of non-standard u_int*_t types

Looks fine to me, too. There are several reasons why libEBML uses its
own typedefs: back when it was started (around… 2002?) cross-platform
support for the C99 types was abysmal, and we only received full
autoconf support this year.

Nowadays we can just include inttypes.h and use the C99 variants.

What we cannot do is getting rid of our typedefs altogether (the ones
without the _t suffixes) as that would break existing code.

> 4. CloudABI specific: disable StdIOCallback

Yeah, that's not acceptable as-is for upstreaming.

However, if you're willing to implement what I've talked about in
1. (making the configure-generated config.h part of the libEBML
installation) then I would definitely accept a patch that adds an option
to configure for compiling without StdIOCallback.

That's more work but it would allow your patch to be upstreamed.

Kind regards,
mosu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20151118/62fefb62/attachment.sig>


More information about the Matroska-devel mailing list