build failure with gcc 13

[emollier]

Hi,

vbz_compression currently fails to build from source with gcc 13.1.0 currently in Debian sid. Relevant error messages are:

In file included from /<<PKGBUILDDIR>>/vbz/v0/vbz_streamvbyte.cpp:2:
/<<PKGBUILDDIR>>/vbz/v0/vbz_streamvbyte_impl.h: In static member function ‘static vbz_size_t StreamVByteWorkerV0<T, UseZigZag>::compress(gsl::span<const char>, gsl::span<char>)’:
/<<PKGBUILDDIR>>/vbz/v0/vbz_streamvbyte_impl.h:22:43: error: ‘uint32_t’ is not a member of ‘std’; did you mean ‘wint_t’?
   22 |             auto input_buffer = cast<std::uint32_t>(input);
      |                                           ^~~~~~~~
      |                                           wint_t
/<<PKGBUILDDIR>>/vbz/v0/vbz_streamvbyte_impl.h:22:43: error: ‘uint32_t’ is not a member of ‘std’; did you mean ‘wint_t’?
   22 |             auto input_buffer = cast<std::uint32_t>(input);
      |                                           ^~~~~~~~
      |                                           wint_t
/<<PKGBUILDDIR>>/vbz/v0/vbz_streamvbyte_impl.h:25:22: error: ‘uint32_t’ is not a member of ‘std’; did you mean ‘wint_t’?
   25 |                 std::uint32_t(input_buffer.size()),
      |                      ^~~~~~~~
      |                      wint_t
[...]

In file included from /<<PKGBUILDDIR>>/vbz/v1/vbz_streamvbyte.cpp:2:
/<<PKGBUILDDIR>>/vbz/v1/vbz_streamvbyte_impl.h: In static member function ‘static vbz_size_t StreamVByteWorkerV1<T, UseZigZag>::compress(gsl::span<const char>, gsl::span<char>)’:
/<<PKGBUILDDIR>>/vbz/v1/vbz_streamvbyte_impl.h:192:43: error: ‘uint32_t’ is not a member of ‘std’; did you mean ‘wint_t’?
  192 |             auto input_buffer = cast<std::uint32_t>(input);
      |                                           ^~~~~~~~
      |                                           wint_t
[...]

I fixed them with the following patch (I can open a merge request if you like):

--- libvbz-hdf-plugin.orig/vbz/v0/vbz_streamvbyte.h
+++ libvbz-hdf-plugin/vbz/v0/vbz_streamvbyte.h
@@ -4,6 +4,7 @@
 #include "vbz.h"
 
 #include <cstddef>
+#include <cstdint>
 
 // Version 1 of streamvbyte
 //
--- libvbz-hdf-plugin.orig/vbz/v1/vbz_streamvbyte.h
+++ libvbz-hdf-plugin/vbz/v1/vbz_streamvbyte.h
@@ -4,6 +4,7 @@
 #include "vbz.h"
 
 #include <cstddef>
+#include <cstdint>
 
 // Version 1 of streamvbyte
 //

But in a subsequent build after applying the patch, I also hit the following issue:

/<<PKGBUILDDIR>>/vbz/vbz.cpp: In function ‘vbz_size_t vbz_decompress_sized(const void*, vbz_size_t, void*, vbz_size_t, const CompressionOptions*)’:
/<<PKGBUILDDIR>>/vbz/vbz.cpp:314:17: error: possibly dangling reference to a temporary [-Werror=dangling-reference]
  314 |     auto const& source_header = source_buffer.subspan(0, sizeof(VbzSizedHeader)).as_span<VbzSizedHeader const>()[0];
      |                 ^~~~~~~~~~~~~
/<<PKGBUILDDIR>>/vbz/vbz.cpp:314:115: note: the temporary was destroyed at the end of the full expression ‘source_buffer.gsl::span<const char>::subspan(0, sizeof ({anonymous}::VbzSizedHeader)).gsl::span<const char>::as_span<const {anonymous}::VbzSizedHeader>().gsl::span<const {anonymous}::VbzSizedHeader>::operator[](0)’
  314 |     auto const& source_header = source_buffer.subspan(0, sizeof(VbzSizedHeader)).as_span<VbzSizedHeader const>()[0];
      |                                                                                                                   ^

As far as I could witness by strolling through the web, this could be an overzealous warning, so I worked around it by building with -Wno-error=dangling-reference, but I thought you might want to be aware of the problem.

This issue was initially reported in Debian Bug#1037746; a full build log is available on qa-logs.debian.net.

[0x55555555]

Hello,

The first typo you refer to in the first code snippet is not in the source here: https://github.com/nanoporetech/vbz_compression/blob/master/vbz/v0/vbz_streamvbyte.h, I'm not sure whats going on there.

On the warnings around source_header, I agree I suspect they are false, but the code isn't particularly readable as is - we can change it to resolve the issue.

Thanks,

• George

[emollier]

Hm, this is embarassing. The csdtint typo was mine and I copy/pasta'ed the wrong build log. I'll edit the issue so it makes sense.

Sorry about my mess.

[emollier]

There there, the first part of the build log should be the appropriate one now. Many thanks for your time! :)

[0x55555555]

Perfect - I've got fixes staged to resolve this - will update when ready.

Thanks,

• George