[Libreoffice-commits] core.git: external/clucene

[Stephan Bergmann (via logerrit)]

 external/clucene/UnpackedTarball_clucene.mk |    1 +
 external/clucene/patches/nullstring.patch   |   11 +++++++++++
 2 files changed, 12 insertions(+)

New commits:
commit 396c0575b2935aeb039e8da260eba739d1a0ed3c
Author:     Stephan Bergmann <sbergman at redhat.com>
AuthorDate: Thu Aug 19 16:43:59 2021 +0200
Commit:     Stephan Bergmann <sbergman at redhat.com>
CommitDate: Thu Aug 19 21:03:45 2021 +0200

    external/clucene: Avoid std::string(nullptr) construction
    
    The relevant constructor is defined as deleted since incorporating
    <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2166r1.html> "A
    Proposal to Prohibit std::basic_string and std::basic_string_view construction
    from nullptr" into the upcoming C++23, and has caused undefined behavior in
    prior versions (see the referenced document for details).  That caused
    
    > workdir/UnpackedTarball/clucene/src/core/CLucene/index/SegmentInfos.cpp:361:13: error: conversion function from 'long' to 'std::string' (aka 'basic_string<char, char_traits<char>, allocator<char>>') invokes a deleted function
    >                    return NULL;
    >                           ^~~~
    > ~/llvm/inst/lib/clang/14.0.0/include/stddef.h:84:18: note: expanded from macro 'NULL'
    > #    define NULL __null
    >                  ^~~~~~
    > ~/llvm/inst/bin/../include/c++/v1/string:849:5: note: 'basic_string' has been explicitly marked deleted here
    >     basic_string(nullptr_t) = delete;
    >     ^
    
    at least when building --with-latest-c++ against recent libc++ 14 trunk (on
    macOS).
    
    (There might be a chance that the CLucene code naively relied on
    SegmentInfo::getDelFileName actually returning a std::string for which c_str()
    would return null at least at some of the call sites, which I did not inspect in
    detail.  However, this would unlikely have worked in the past anyway, as it is
    undefined behavior and at least contemporary libstdc++ throws a std::logic_error
    when constructing a std::string from null, and at least a full `make check` with
    this fix applied built fine for me.)
    
    Change-Id: I2b8cf96b089848d666ec37aa7ee0deacc4798d35
    Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120745
    Tested-by: Jenkins
    Reviewed-by: Stephan Bergmann <sbergman at redhat.com>

diff --git a/external/clucene/UnpackedTarball_clucene.mk b/external/clucene/UnpackedTarball_clucene.mk
index 37c1c16dab0f..a8e697784f9b 100644
--- a/external/clucene/UnpackedTarball_clucene.mk
+++ b/external/clucene/UnpackedTarball_clucene.mk
@@ -50,6 +50,7 @@ $(eval $(call gb_UnpackedTarball_add_patches,clucene,\
 	external/clucene/patches/heap-buffer-overflow.patch \
 	external/clucene/patches/c++20.patch \
 	external/clucene/patches/write-strings.patch \
+	external/clucene/patches/nullstring.patch \
 ))
 
 ifneq ($(OS),WNT)
diff --git a/external/clucene/patches/nullstring.patch b/external/clucene/patches/nullstring.patch
new file mode 100644
index 000000000000..6043e9f00890
--- /dev/null
+++ b/external/clucene/patches/nullstring.patch
@@ -0,0 +1,11 @@
+--- src/core/CLucene/index/SegmentInfos.cpp
++++ src/core/CLucene/index/SegmentInfos.cpp
+@@ -358,7 +358,7 @@
+ 	   if (delGen == NO) {
+ 		   // In this case we know there is no deletion filename
+ 		   // against this segment
+-		   return NULL;
++		   return {};
+ 	   } else {
+ 		   // If delGen is CHECK_DIR, it's the pre-lockless-commit file format
+ 		   return IndexFileNames::fileNameFromGeneration(name.c_str(), (string(".") + IndexFileNames::DELETES_EXTENSION).c_str(), delGen);