Fix C++ client time column access returning NULL for non-long types (#17397)

[PDGGK]

Description

Fixes #17397

Several ByTsBlockColumnIndex getter methods in IoTDBRpcDataSet.cpp did not handle the tsBlockColumnIndex < 0 case (time pseudo-column in tree model), causing undefined behavior when the time column was accessed through typed getters other than getLong or getString.

In tree model, column index 1 maps to tsBlockColumnIndex = -1 (the time column). When a user calls getBooleanByIndex(1), this flows to getBooleanByTsBlockColumnIndex(-1), which calls curTsBlock_->getColumn(-1) — an out-of-bounds std::vector access (UB in C++).

Only getLongByTsBlockColumnIndex and getStringByTsBlockColumnIndex correctly handled the < 0 case. The following five methods were missing the guard:

Method	Fix
getBooleanByTsBlockColumnIndex	Throw IoTDBException (boolean from timestamp is nonsensical)
getDoubleByTsBlockColumnIndex	Return timestamp cast to double
getFloatByTsBlockColumnIndex	Return timestamp cast to float
getIntByTsBlockColumnIndex	Return timestamp cast to int32_t
getBinaryByTsBlockColumnIndex	Return timestamp as Binary string

Design Discussion

For the numeric types (int, float, double), I chose to return the timestamp value (cast to the target type) to stay consistent with getLongByTsBlockColumnIndex which already returns the timestamp. However, an alternative approach would be to throw IoTDBException for all non-long/non-string types, since:

• static_cast<int32_t>(timestamp) silently truncates 64-bit timestamps
• Accessing a time column as float or boolean is likely a user error

I'd appreciate the maintainers' preference on which approach is better. Happy to change if throwing is preferred.

Note

The Java client (IoTDBRpcDataSet.java) has the same asymmetry — only getLong and getString handle tsBlockColumnIndex < 0. The other typed getters (getBoolean, getInt, getFloat, getDouble, getBinary) will throw IndexOutOfBoundsException in Java. This could be addressed as a follow-up.

[jt2594838]

Good job!

Well, I doubt if it is a good idea to support returning int32 and float, because the data will probably be incorrect (I can't even say it is a precision loss) due to overflow.

It will be better to add some comments in the method definitions to point out the potential risk.

Also, please add a unit test or an integration test for the targeted scenario and take a look at the failed tests.

[HTHou]

And please rebase the latest master branch, the failed c++ tests should already be fixed now.

[CritasWang]

Great catch on the vector out-of-bounds UB in IoTDBRpcDataSet.cpp!

Regarding your design question: I strongly prefer throwing IoTDBException for getBoolean, getInt, getFloat, and getDouble when tsBlockColumnIndex < 0.
Silently casting a 64-bit timestamp to int32_t or float will cause severe precision loss and data truncation that is incredibly hard to debug for users. A fast-fail exception (e.g., IoTDBException("Cannot read [type] from time column")) is much safer, and it aligns perfectly with our Java client which typically throws IndexOutOfBoundsException or ClassCastException for mismatched types on the Time column.

Could you please update the numeric getters to throw exceptions instead of casting?

[PDGGK]

Thanks for the reviews @jt2594838 @HTHou @CritasWang!

I agree — silently casting a 64-bit timestamp to int32/float is dangerous. I'll update all non-long/non-string getters to throw IoTDBException("Cannot read <type> from time column") instead of casting.

Summary of changes coming:

1. Change getInt, getFloat, getDouble, getBinary guards from cast to throw (keep getBoolean as-is, already throws)
2. Rebase onto latest master
3. Add test coverage for the boolean scenario

Will push the update shortly.