ianmcook opened a new issue, #51780:
URL: https://github.com/apache/arrow/issues/51780

   > [!NOTE]
   > I discovered this issue and wrote it up with help from Claude Opus 5.5.
   
   ### Describe the enhancement requested
   
   In 
[`GetSchema`](https://github.com/apache/arrow/blob/e85e181188ac3c5e8407b2160331faf5e78fd429/cpp/src/arrow/ipc/metadata_internal.cc#L1450-L1457)
 in `cpp/src/arrow/ipc/metadata_internal.cc`, the loop over a schema's fields 
checks each field for null with the wrong label:
   
   ```cpp
   for (int i = 0; i < num_fields; ++i) {
     const flatbuf::Field* field = schema->fields()->Get(i);
     // XXX I don't think this check is necessary (AP)
     CHECK_FLATBUFFERS_NOT_NULL(field, "DictionaryEncoding.indexType");
     RETURN_NOT_OK(
         FieldFromFlatbuffer(field, field_pos.child(i), dictionary_memo, 
&fields[i]));
   }
   ```
   
   The value being checked is a `Field`, not `DictionaryEncoding.indexType`. If 
the check ever failed, it would report `Unexpected null field 
DictionaryEncoding.indexType in flatbuffer-encoded metadata`. That message 
already belongs to the real check on dictionary index types at [line 
901](https://github.com/apache/arrow/blob/e85e181188ac3c5e8407b2160331faf5e78fd429/cpp/src/arrow/ipc/metadata_internal.cc#L899-L902),
 so the two errors would be indistinguishable.
   
   As the comment beside it suggests, the check also appears unable to fail. 
For a vector of tables, the vendored flatbuffers 
[`IndirectHelper<Offset<T>>::Read`](https://github.com/apache/arrow/blob/e85e181188ac3c5e8407b2160331faf5e78fd429/cpp/thirdparty/flatbuffers/include/flatbuffers/buffer.h#L121-L130)
 returns the element's address plus its stored offset, so `fields()->Get(i)` 
doesn't return null. The function already checks `schema->fields()` itself for 
null, with the correct label `Schema.fields`.
   
   Either option would fix it:
   
   - Remove the check, as the comment suggests.
   - Keep it with an accurate label, such as `"Schema.fields[i]"`.
   
   I found this while looking into how the reader handles a missing 
`DictionaryEncoding.indexType`, which is reported separately at #51779.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to