waddou / libass

Automatically exported from code.google.com/p/libass
1 stars 0 forks source link

add library version api #113

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Motivation for this request:

There is no library's version information.

Description of the feature or improvement:

Current, Version definition is existed in ass.h header file.
It is not a library's own version information.

When I uses the dynamic library of libass, there is no way to recognize a 
library's version.

So, I add an API that returns a library' version.

Original issue reported on code.google.com by chadr...@gmail.com on 9 Nov 2013 at 2:28

Attachments:

GoogleCodeExporter commented 8 years ago
OK, but why do you think you need this?

Also, should the return value really be uint32_t instead of int? Using a fixed 
width type here seems a bit strange.

Original comment by nfxjfg@googlemail.com on 9 Nov 2013 at 2:14

GoogleCodeExporter commented 8 years ago
I can't think of any immediate need for this, but it still might be useful to 
have. I'd also rather like to see a normal int as the return type, though.

Original comment by g...@chown.ath.cx on 9 Nov 2013 at 4:28

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
If you need to branch the code flow with libass version or for debugging 
application what version is now using to know, it maybe useful.

I think that fixed width of uint32_t is more clear to recognize the size of 
version data.

Because of int have variable with each arch(ex, 32bit, 64bit...), it need to 
make clear width.

if LIBASS_VERSION defined as 0x101001020000, it is not int width in 32bit 
arch.(if later.... not now :) )
So, I think when use the defined numberic constant, it have to loaded in fixed 
width variable.

Original comment by chadr...@gmail.com on 10 Nov 2013 at 2:02

GoogleCodeExporter commented 8 years ago
Merged with modifications.

Original comment by nfxjfg@googlemail.com on 25 Nov 2013 at 11:22