GH-49274: [Doc][C++] Address review follow-ups by zanmato1984 · Pull Request #69 · zanmato1984/arrow

zanmato1984 · 2026-03-26T08:23:09Z

Summary

follow up on the unresolved review comments from GH-49274: [Doc][C++] Document security model for Arrow C++ apache/arrow#49489
clarify the Status/Result wording in the C++ security model docs
promote Data validity and "Safe" and "unsafe" APIsto top-level sections and qualify when to preferArrayDataoverArraySpan`

Context

upstream PR: GH-49274: [Doc][C++] Document security model for Arrow C++ apache/arrow#49489
case issue: https://github.com/zanmato1984/omar/issues/32

Testing

git diff --check
attempted local docs validation, but this environment does not currently have Sphinx/docutils/doxygen installed

…ple (apache#49554) ### Rationale for this change The current documentation contains a technical inconsistency in the validity bitmap values for column 4. According to the Arrow specification: > In Arrow, a dedicated buffer, known as the validity (or “null”) bitmap, is used alongside the data indicating whether each value in the array is null or not: a value of 1 means that the value is not-null (“valid”), whereas a value of 0 indicates that the value is null. In the existing example, the validity bitmap for the third row of the variable-size binary child array is incorrectly set to 1, despite the row being null. This PR corrects that bit to 0 to align with the fixed-size primitive child array and the overall Arrow memory layout standards. ### What changes are included in this PR? Updated the struct-diagram.svg ### Are these changes tested? No ### Are there any user-facing changes? No Authored-by: Philipp Ucke <philippucke@googlemail.com> Signed-off-by: Raúl Cumplido <raulcumplido@gmail.com>

…ia lib.pyx (apache#49515) ### Rationale for this change Running `python -m pytest --doctest-cython` directly on `.pxi` files doesn't work because Cython `.pxi` files are included in `.pyx` files at compile time. This isn't documented, which could _potentially_ confuse contributors. Please see discussion in apache#49279 (comment) by @ AlenkaF for additional context. ### What changes are included in this PR? Added a `note` to the Doctest section of the Developing PyArrow documentation explaining that: - `.pxi` files cannot be tested directly with `--doctest-cython` - Doctests should be run on the `.pyx` file they are included in (e.g., `lib.pyx`) - Errors will appear under the `.pyx` file, not the original `.pxi` filename ### Are these changes tested? Documentation-only change. No code changes. ### Are there any user-facing changes? No. * GitHub Issue: apache#49503 Lead-authored-by: Bhavana Sundar <bhavana7899@gmail.com> Co-authored-by: Alenka Frim <AlenkaF@users.noreply.github.com> Signed-off-by: AlenkaF <frim.alenka@gmail.com>

### Rationale for this change Performance is important in Apache Arrow. So benchmark is useful for developing Apache Arrow implementation. ### What changes are included in this PR? * Add benchmarks for file and streaming readers. * Add support for `mmap` in streaming reader. Here are benchmark results on my environment. Pure Ruby implementation is about 5-6x slower than release build C++ implementation but a bit faster than debug build C++ implementation. Release build C++/GLib: File format: ```console $ ruby -v -S benchmark-driver ruby/red-arrow-format/benchmark/file-reader.yaml ruby 4.1.0dev (2026-02-19T09:04:23Z master 6bb0b6b16c) +PRISM [x86_64-linux] Warming up -------------------------------------- Arrow::Table.load 11.207k i/s - 12.188k times in 1.087487s (89.23μs/i) Arrow::RecordBatchFileReader 19.724k i/s - 21.296k times in 1.079727s (50.70μs/i) ArrowFormat::FileReader 3.555k i/s - 3.883k times in 1.092223s (281.28μs/i) Calculating ------------------------------------- Arrow::Table.load 11.483k i/s - 33.622k times in 2.928024s (87.09μs/i) Arrow::RecordBatchFileReader 19.673k i/s - 59.170k times in 3.007729s (50.83μs/i) ArrowFormat::FileReader 3.574k i/s - 10.665k times in 2.984214s (279.81μs/i) Comparison: Arrow::RecordBatchFileReader: 19672.6 i/s Arrow::Table.load: 11482.8 i/s - 1.71x slower ArrowFormat::FileReader: 3573.8 i/s - 5.50x slower ``` Streaming format: ```console $ ruby -v -S benchmark-driver ruby/red-arrow-format/benchmark/streaming-reader.yaml ruby 4.1.0dev (2026-02-19T09:04:23Z master 6bb0b6b16c) +PRISM [x86_64-linux] Warming up -------------------------------------- Arrow::Table.load 11.360k i/s - 12.485k times in 1.099067s (88.03μs/i) Arrow::RecordBatchStreamReader 20.180k i/s - 21.857k times in 1.083126s (49.56μs/i) ArrowFormat::StreamingReader 3.398k i/s - 3.400k times in 1.000479s (294.26μs/i) Calculating ------------------------------------- Arrow::Table.load 11.397k i/s - 34.078k times in 2.990170s (87.74μs/i) Arrow::RecordBatchStreamReader 20.039k i/s - 60.538k times in 3.020964s (49.90μs/i) ArrowFormat::StreamingReader 3.340k i/s - 10.195k times in 3.052059s (299.37μs/i) Comparison: Arrow::RecordBatchStreamReader: 20039.3 i/s Arrow::Table.load: 11396.7 i/s - 1.76x slower ArrowFormat::StreamingReader: 3340.4 i/s - 6.00x slower ``` Debug build C++/GLib: File format: ```console $ ruby -v -S benchmark-driver ruby/red-arrow-format/benchmark/file-reader.yaml ruby 4.1.0dev (2026-02-19T09:04:23Z master 6bb0b6b16c) +PRISM [x86_64-linux] Warming up -------------------------------------- Arrow::Table.load 2.175k i/s - 2.200k times in 1.011375s (459.72μs/i) Arrow::RecordBatchFileReader 3.129k i/s - 3.421k times in 1.093397s (319.61μs/i) ArrowFormat::FileReader 3.384k i/s - 3.430k times in 1.013625s (295.52μs/i) Calculating ------------------------------------- Arrow::Table.load 2.145k i/s - 6.525k times in 3.041760s (466.17μs/i) Arrow::RecordBatchFileReader 3.020k i/s - 9.386k times in 3.108456s (331.18μs/i) ArrowFormat::FileReader 3.368k i/s - 10.151k times in 3.013576s (296.87μs/i) Comparison: ArrowFormat::FileReader: 3368.4 i/s Arrow::RecordBatchFileReader: 3019.5 i/s - 1.12x slower Arrow::Table.load: 2145.1 i/s - 1.57x slower ``` Streaming format: ```console $ ruby -v -S benchmark-driver ruby/red-arrow-format/benchmark/streaming-reader.yaml ruby 4.1.0dev (2026-02-19T09:04:23Z master 6bb0b6b16c) +PRISM [x86_64-linux] Warming up -------------------------------------- Arrow::Table.load 2.115k i/s - 2.140k times in 1.011815s (472.81μs/i) Arrow::RecordBatchStreamReader 3.052k i/s - 3.355k times in 1.099273s (327.65μs/i) ArrowFormat::StreamingReader 3.283k i/s - 3.290k times in 1.002016s (304.56μs/i) Calculating ------------------------------------- Arrow::Table.load 2.198k i/s - 6.345k times in 2.886603s (454.94μs/i) Arrow::RecordBatchStreamReader 3.105k i/s - 9.156k times in 2.948523s (322.03μs/i) ArrowFormat::StreamingReader 3.225k i/s - 9.850k times in 3.054339s (310.09μs/i) Comparison: ArrowFormat::StreamingReader: 3224.9 i/s Arrow::RecordBatchStreamReader: 3105.3 i/s - 1.04x slower Arrow::Table.load: 2198.1 i/s - 1.47x slower ``` ### Are these changes tested? Yes. ### Are there any user-facing changes? No. * GitHub Issue: apache#49544 Authored-by: Sutou Kouhei <kou@clear-code.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>

…che#49577) ### Rationale for this change In file format, Footer can have custom metadata. ### What changes are included in this PR? * Add `garrow_record_batch_file_reader_get_metadata()` * Add `garrow_record_batch_file_writer_new_full()` * Add `ArrowFormat::FileReader#metadata` * Add `metadata` to `ArrowFormat::FileWriter#finish` * Add `metadata:` to `Arrow::Table#save` ### Are these changes tested? Yes. ### Are there any user-facing changes? Yes. * GitHub Issue: apache#49576 Authored-by: Sutou Kouhei <kou@clear-code.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>

…tryBounder::MergeGeometryInternal (apache#49558) ### Rationale for this change Fix `MergeGeometryInternal` stack overflow from deeply nested WKB GeometryCollection inputs. ### What changes are included in this PR? Added a depth limit (128) to `MergeGeometryInternal` to prevent stack overflow when parsing deeply nested WKB GeometryCollection inputs. ### Are these changes tested? A unit test `TestWKBBounderErrorForDeepNesting` has been included to ensure proper exception throwing upon exceeding the limit. ### Are there any user-facing changes? No. * GitHub Issue: apache#49559 Lead-authored-by: Gang Wu <ustcwg@gmail.com> Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com> Co-authored-by: wgtmac <4684607+wgtmac@users.noreply.github.com> Signed-off-by: Gang Wu <ustcwg@gmail.com>

… deciding whether to use std::bit_width or std::log2p1 (apache#49570) ### Rationale for this change Clang 15.0.7 (/opt/homebrew/bin/clang++) - Homebrew LLVM fails compiling with: ``` FAILED: [code=1] CMakeFiles/arrow_python.dir/pyarrow/src/arrow/python/arrow_to_pandas.cc.o /opt/homebrew/bin/ccache /opt/homebrew/bin/clang++ -DARROW_HAVE_NEON -DARROW_PYTHON_EXPORTING -Darrow_python_EXPORTS -I/Users/runner/work/arrow/arrow/build/python/pyarrow/src -I/var/folders/gj/d1t24fg93wbdl854js_qwvb00000gn/T/tmpj20nqu3c/build/pyarrow/src -I/Library/Frameworks/Python.framework/Versions/3.11/include/python3.11 -I/tmp/local/include -I/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/numpy/_core/include -fno-aligned-new -Wall -Wno-unknown-warning-option -Wno-pass-failed -march=armv8-a -Qunused-arguments -fcolor-diagnostics -fno-omit-frame-pointer -Wno-unused-variable -Wno-maybe-uninitialized -Wno-parentheses-equality -Wno-constant-logical-operand -Wno-missing-declarations -Wno-sometimes-uninitialized -Wno-return-type-c-linkage -g -O0 -std=c++20 -arch arm64 -mmacosx-version-min=12 -fPIC -Wno-parentheses-equality -MD -MT CMakeFiles/arrow_python.dir/pyarrow/src/arrow/python/arrow_to_pandas.cc.o -MF CMakeFiles/arrow_python.dir/pyarrow/src/arrow/python/arrow_to_pandas.cc.o.d -o CMakeFiles/arrow_python.dir/pyarrow/src/arrow/python/arrow_to_pandas.cc.o -c /Users/runner/work/arrow/arrow/build/python/pyarrow/src/arrow/python/arrow_to_pandas.cc In file included from /Users/runner/work/arrow/arrow/build/python/pyarrow/src/arrow/python/arrow_to_pandas.cc:34: In file included from /tmp/local/include/arrow/array.h:41: In file included from /tmp/local/include/arrow/array/array_base.h:26: In file included from /tmp/local/include/arrow/array/data.h:32: /tmp/local/include/arrow/util/bit_util.h:145:15: error: no member named 'log2p1' in namespace 'std' return std::log2p1(x - 1); ~~~~~^ 1 error generated. ``` This seems to be the case of clang not having `__cpp_lib_bitops` defined but `std::log2p1` having been removed. ### What changes are included in this PR? Check for `__apple_build_version__` instead of `__clang__` so non Apple Clang just uses `std::bit_width` ### Are these changes tested? Via CI ### Are there any user-facing changes? No * GitHub Issue: apache#49569 Authored-by: Raúl Cumplido <raulcumplido@gmail.com> Signed-off-by: Raúl Cumplido <raulcumplido@gmail.com>

@thisisnic

…x r-de… (apache#49381) ### Rationale for this change The `r-devdocs` crossbow CI job fails during the gap between the C++ release (published to apt) and the R package release (CRAN). Two hidden bash chunks in `setup.Rmd` were silently installing the released `libarrow-dev` from apt during CI, overwriting the version built from the git checkout. Since the R package (`arrow.so`) was compiled against the newer git-built `libarrow`, loading it against the older apt version caused an undefined symbol ABI mismatch error. ### What changes are included in this PR? Removes the hidden CI test chunks from `r/vignettes/developers/setup.Rmd`: - Removed hidden macOS chunk that ran `brew install apache-arrow` - Removed hidden Ubuntu chunk that ran `apt install libarrow-dev` (root cause of the ABI mismatch) - Converted the `MAKEFLAGS="LDFLAGS="` example from an executable knitr chunk to a plain `bash` code block preserves the documentation example without executing it in CI ### Are these changes tested? No, the fix removes the broken test logic from the vignette. As noted by @thisisnic, this type of testing should live in proper CI infrastructure, not embedded as hidden code in documentation. ### Are there any user-facing changes? No. The rendered documentation is unchanged the `MAKEFLAGS="LDFLAGS="` example remains visible in the "Multiple versions of libarrow" troubleshooting section. * GitHub Issue: apache#49380 --------- Co-authored-by: vanshaj2023 <vanshaj2023@users.noreply.github.com> Co-authored-by: Jonathan Keane <jkeane@gmail.com>

### Rationale for this change Fix the build on MacOS with newest xsimd version. A fix for an internal bug in xsimd had been added in apacheGH-49449 apacheGH-49450 to boost performances. Now that the fix has been merged in xsimd 14.1.0, the internals have changed leading to the failure. The ported fix is kept for older xsimd versions until we can set a minimum xsimd version of 14.1.0. ### What changes are included in this PR? Remove a backported fix on xsimd versions that include it. ### Are these changes tested? Yes. ### Are there any user-facing changes? No. * GitHub Issue: apache#49579 Authored-by: AntoinePrv <AntoinePrv@users.noreply.github.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>

…ring literals in test suite (apache#49562) ### Rationale for this change We want to use a SQLWCHAR array for wide string literal inside our test suite instead of a SQLWCHAR vector. ### What changes are included in this PR? SQLWCHAR vector used for wide string literals are replaced with a SQLWCHAR array instead. Columns tests were refactored to perform assertions over std::string equality rather than wide string equality. ### Are these changes tested? Yes ### Are there any user-facing changes? No * GitHub Issue: apache#49561 Authored-by: justing-bq <62349012+justing-bq@users.noreply.github.com> Signed-off-by: David Li <li.davidm96@gmail.com>

### Rationale for this change C++ 20 already includes a span implementation so there is no reason to maintain a custom one in utils as described in apache#48588 ### What changes are included in this PR? arrow::utils::span definition and tests are removed and usages are replaced with std::span. Some span comparisons in tests are replaced from ASSERT_EQ to ASSERT_TRUE(std::ranges::equal(span1, span2)) because ASSERT_EQ inernally relies on == operator which is not defined for some types that we used to compare. ### Are these changes tested? Yes ### Are there any user-facing changes? No * GitHub Issue: apache#48588 Lead-authored-by: Paweł Biegun <biegunpawel900@gmail.com> Co-authored-by: Will Ayd <william.ayd@icloud.com> Signed-off-by: Antoine Pitrou <antoine@python.org>

…rInFrame (apache#49530) ### Rationale for this change CI job shows NOTE due to "non-API call" Rf_findVarInFrame ### What changes are included in this PR? Remove non-API calls to doesn't come up on CRAN notes ### Are these changes tested? I'll do some CI testing ### Are there any user-facing changes? No ### AI use Basically all of this, with Claude Opus 4.5 but I did ask multiple questions on the reasoning behind the changes and alternatives - don't understand 100% but looks reasonable to me * GitHub Issue: apache#49529 Authored-by: Nic Crane <thisisnic@gmail.com> Signed-off-by: Nic Crane <thisisnic@gmail.com>

### Rationale for this change Resolve the crossbow failure, I've already created an issue upstream ### What changes are included in this PR? Skipping a test under sanitization ### Are these changes tested? They are the tests ### Are there any user-facing changes? No * GitHub Issue: apache#49578 Authored-by: Jonathan Keane <jkeane@gmail.com> Signed-off-by: Nic Crane <thisisnic@gmail.com>

### Rationale for this change Cherry-picking the NEWS.md updates from the R patch release branches ### What changes are included in this PR? NEWS updates ### Are these changes tested? No ### Are there any user-facing changes? No Authored-by: Nic Crane <thisisnic@gmail.com> Signed-off-by: Nic Crane <thisisnic@gmail.com>

…to move the const received one (apache#49567) ### Rationale for this change The [test-ubuntu-22.04-python-313-freethreading](https://github.com/ursacomputing/crossbow/actions/runs/23324175137/job/67841753438) job is currently failing with: ``` [104/119] Building CXX object CMakeFiles/_parquet_encryption.dir/_parquet_encryption.cpp.o FAILED: CMakeFiles/_parquet_encryption.dir/_parquet_encryption.cpp.o /usr/bin/ccache /usr/lib/ccache/x86_64-linux-gnu-g++ -DARROW_HAVE_RUNTIME_AVX2 -DARROW_HAVE_RUNTIME_AVX512 -DARROW_HAVE_RUNTIME_BMI2 -DARROW_HAVE_RUNTIME_SSE4_2 -DARROW_HAVE_SSE4_2 -D_parquet_encryption_EXPORTS -I/usr/include/python3.13t -I/build/python/pyarrow/src -I/tmp/tmp2y9fbxsg/build/pyarrow/src -I/arrow-dev/lib/python3.13t/site-packages/numpy/_core/include -Wno-noexcept-type -Wall -fno-semantic-interposition -msse4.2 -fdiagnostics-color=always -fno-omit-frame-pointer -Wno-unused-variable -Wno-maybe-uninitialized -g -O0 -std=c++20 -fPIC -Wno-unused-function -MD -MT CMakeFiles/_parquet_encryption.dir/_parquet_encryption.cpp.o -MF CMakeFiles/_parquet_encryption.dir/_parquet_encryption.cpp.o.d -o CMakeFiles/_parquet_encryption.dir/_parquet_encryption.cpp.o -c /tmp/tmp2y9fbxsg/build/_parquet_encryption.cpp /tmp/tmp2y9fbxsg/build/_parquet_encryption.cpp: In function ‘PyObject* __pyx_f_7pyarrow_19_parquet_encryption_19KmsConnectionConfig_wrap(const parquet::encryption::KmsConnectionConfig&)’: /tmp/tmp2y9fbxsg/build/_parquet_encryption.cpp:16576:137: error: binding reference of type ‘parquet::encryption::KmsConnectionConfig&’ to ‘const parquet::encryption::KmsConnectionConfig’ discards qualifiers 16576 | __pyx_t_4 = std::make_shared< parquet::encryption::KmsConnectionConfig>(cython_std::move< parquet::encryption::KmsConnectionConfig>(__pyx_v_config)); | ^~~~~~~~~~~~~~ /tmp/tmp2y9fbxsg/build/_parquet_encryption.cpp:1171:77: note: initializing argument 1 of ‘typename std::remove_reference<_Tp>::type&& cython_std::move(T&) [with T = parquet::encryption::KmsConnectionConfig; typename std::remove_reference<_Tp>::type = parquet::encryption::KmsConnectionConfig]’ 1171 | template <typename T> typename std::remove_reference<T>::type&& move(T& t) noexcept { return std::move(t); } | ``` ### What changes are included in this PR? Copy CKmsConnectionConfig instead of trying to move the const one owned by C++. ### Are these changes tested? Yes via archery ### Are there any user-facing changes? No * GitHub Issue: apache#49565 Authored-by: Raúl Cumplido <raulcumplido@gmail.com> Signed-off-by: Raúl Cumplido <raulcumplido@gmail.com>

…pache#47397) ### Rationale for this change CSV and JSON options lack a nice repr/str dunder method ### What changes are included in this PR? Add both these methods ### Are these changes tested? Will be once it's ready for review ### Are there any user-facing changes? No * GitHub Issue: apache#47389 Lead-authored-by: Nic Crane <thisisnic@gmail.com> Co-authored-by: AlenkaF <frim.alenka@gmail.com> Co-authored-by: Alenka Frim <AlenkaF@users.noreply.github.com> Signed-off-by: AlenkaF <frim.alenka@gmail.com>

…apache#49597) ### Rationale for this change A new PyGithub release has broken archery: https://github.com/PyGithub/PyGithub/releases/tag/v2.9.0 I tried some quick test error fixes but those are going to require more investigation. ### What changes are included in this PR? Pin PyGithub to < 2.9 so archery doesn't fail. ### Are these changes tested? Yes via CI ### Are there any user-facing changes? No * GitHub Issue: apache#49596 Authored-by: Raúl Cumplido <raulcumplido@gmail.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>

…ython files and other Python release verification fixes (apache#49571) ### Rationale for this change Local import is broken when doing editable install with scikit-build-core, also nightly verification jobs are failing for the same reason. ### What changes are included in this PR? - `lib.h` and `lib_api.h` are already installed separately so we skip them when installing Cython extensions into the output destination (`side-packages/pyarrow`). - Arrow library directory is added to the `RPATH`, in the case of not bundling ARROW_CPP, to fix linking issues on macos - `test_pyarrow_include` is updated due to compiled files now being moved to the site-packages - updates to the release verification script when building pyarrow - update of `brew` on the "Install System Dependencies" step in the rc verification job to fix an issue with protobuf mixed versions ### Are these changes tested? Yes, locally and via the extended verification builds. ### Are there any user-facing changes? No. * GitHub Issue: apache#49566 Lead-authored-by: Raúl Cumplido <raulcumplido@gmail.com> Co-authored-by: AlenkaF <frim.alenka@gmail.com> Signed-off-by: Raúl Cumplido <raulcumplido@gmail.com>

…te the information (apache#49573) ### Rationale for this change Editable install section in the Python dev docs became redundant with the new scikit-build-core backend. ### What changes are included in this PR? Update docs. ### Are these changes tested? No, just docs changes. ### Are there any user-facing changes? No. * GitHub Issue: apache#49572 Authored-by: AlenkaF <frim.alenka@gmail.com> Signed-off-by: Raúl Cumplido <raulcumplido@gmail.com>

…package (apache#49594) ### Rationale for this change fs package release no longer installs bundled libuv so we need to add it to our CI ### What changes are included in this PR? Add libuv to R install scripts on CI ### Are these changes tested? I'll run CI ### Are there any user-facing changes? No * GitHub Issue: apache#49593 Authored-by: Nic Crane <thisisnic@gmail.com> Signed-off-by: Nic Crane <thisisnic@gmail.com>

…he#49575) ### Rationale for this change apacheGH-49563 ### What changes are included in this PR? This issue occurred without any code changes, so I think it is due to an macOS update. After a GitHub macOS update, the `CLANG_TOOLS_PATH` path is resolved as `/usr/local/bin/clang-format` in Intel CI. Before the GitHub macOS update, `CLANG_TOOLS_PATH` was resolved as `/usr/local/opt/llvm@ 18/bin` and we did not have the issue of `libunwind` linking dynamically to ODBC dylib. We don't know why clang tools change is related to `libunwind` linking but we don't need to detect clang/infer tools in our CMake now. (We migrated to pre-commit from Archery for linting.) So we can fix this issue by removing clang/infer tools detection from our CMake configuration. ### Are these changes tested? - Tested in CI ### Are there any user-facing changes? N/A * GitHub Issue: apache#49563 Lead-authored-by: Alina (Xi) Li <alina.li@improving.com> Co-authored-by: Alina (Xi) Li <96995091+alinaliBQ@users.noreply.github.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>

github-actions · 2026-03-26T09:38:57Z

❌ GitHub issue apache#49274 could not be retrieved.

pucke-dev and others added 22 commits March 20, 2026 13:41

apacheGH-49274: [Doc][C++] Document security model for Arrow C++

3843f52

apacheGH-49274: [Doc][C++] Address review follow-ups

dc9edf1

github-actions Bot added the awaiting review label Mar 26, 2026

zanmato1984 closed this Mar 26, 2026

zanmato1984 deleted the case-32-arrow-49489-followups branch March 26, 2026 08:29

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

GH-49274: [Doc][C++] Address review follow-ups#69

GH-49274: [Doc][C++] Address review follow-ups#69
zanmato1984 wants to merge 22 commits into
mainfrom
case-32-arrow-49489-followups

zanmato1984 commented Mar 26, 2026

Uh oh!

github-actions Bot commented Mar 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

15 participants

Conversation

zanmato1984 commented Mar 26, 2026

Summary

Context

Testing

Uh oh!

github-actions Bot commented Mar 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

15 participants