On Mon, Apr 02 2018, Rafael Sadowski <[email protected]> wrote:
> Could it be tested in a bulk build please?
>
> Best regards, Rafael Sadowski
>
> On Thu Mar 15, 2018 at 05:51:37PM +0100, Rafael Sadowski wrote:
>> Update exiv2 to the latest stable version. Only tested with upcoming
>> digikam 5.8.0. 14971 jpeg pictures don't cause any problems.
>>
>> I don't expect any problems but to be on the safe side could someone
>> push it into an the next bulk?
>>
>> ok? Comments?
Looks good to me, a bulk could be a good idea indeed. One nit though,
[...]
>> Index: patches/patch-src_actions_cpp
>> ===================================================================
>> RCS file: patches/patch-src_actions_cpp
>> diff -N patches/patch-src_actions_cpp
>> --- /dev/null 1 Jan 1970 00:00:00 -0000
>> +++ patches/patch-src_actions_cpp 15 Mar 2018 09:28:45 -0000
>> @@ -0,0 +1,14 @@
>> +$OpenBSD$
>> +
>> +Index: src/actions.cpp
>> +--- src/actions.cpp.orig
>> ++++ src/actions.cpp
>> +@@ -2049,7 +2049,7 @@ namespace {
>> + /* This is the critical section object (statically allocated). */
>> + static pthread_mutex_t cs = PTHREAD_RECURSIVE_MUTEX_INITIALIZER;
>> + #else
>> +- static pthread_mutex_t cs = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
>> ++ static pthread_mutex_t cs = PTHREAD_MUTEX_INITIALIZER;
By default pthread mutexes aren't recursive, this would be a problem if
exiv2 actually wants recursive mutexes. With no static initializer for
this type of mutex, I'll admit that it's a bit cumbersome to use.
Looking more closely, the code in temporaryPath() looks like a hacked
up, unsafe mkstemp(3). I'm not sure how this should be handled.
>> + #endif
>> + #endif
>> +
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
