[CLucene-dev] Fwd: [Libreoffice-commits] core.git: external/clucene: Avoid std::string(nullptr) construction

[Stephan B. <sbe...@re...>]

FYI:


-------- Forwarded Message --------
Subject: [Libreoffice-commits] core.git: external/clucene
Date: Thu, 19 Aug 2021 19:04:20 +0000 (UTC)
From: Stephan Bergmann (via logerrit) <log...@ke...>
Reply-To: lib...@li...
To: lib...@li...

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

New commits:
commit 396c0575b2935aeb039e8da260eba739d1a0ed3c
Author:     Stephan Bergmann <sbe...@re...>
AuthorDate: Thu Aug 19 16:43:59 2021 +0200
Commit:     Stephan Bergmann <sbe...@re...>
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 <sbe...@re...>

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);