This is an automated email from the ASF dual-hosted git repository.
airborne12 pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/doris.git
The following commit(s) were added to refs/heads/master by this push:
new 05690fce06f [fix](compile) disambiguate Aws::Utils::DateTime ctor in
kinesis_conf (#63727)
05690fce06f is described below
commit 05690fce06f6daa119ca2b77c014865215cdc540
Author: Jack <[email protected]>
AuthorDate: Wed May 27 20:08:29 2026 +0800
[fix](compile) disambiguate Aws::Utils::DateTime ctor in kinesis_conf
(#63727)
### What problem does this PR solve?
Issue Number: N/A
Related PR: N/A
Problem Summary:
`be/src/load/routine_load/kinesis_conf.cpp:118` constructs
`Aws::Utils::DateTime` from `std::stol(...)`. The AWS SDK declares two
constructors:
```cpp
DateTime(int64_t millisSinceEpoch);
DateTime(double epoch_millis);
```
On macOS ARM64 (Apple LP64 with libc++), `int64_t` is typedef'd to `long
long` — distinct from the `long` that `std::stol` returns. Both `long ->
long long` and `long -> double` are same-rank conversions, so overload
resolution is ambiguous and the build fails:
```
error: ambiguous conversion for functional-style cast from 'long' to
'Aws::Utils::DateTime'
118 |
request.SetTimestamp(Aws::Utils::DateTime(std::stol(it->second)));
note: candidate constructor DateTime(int64_t millisSinceEpoch);
note: candidate constructor DateTime(double epoch_millis);
```
Note: a naive switch to `std::stoll` would *symmetrically* break Linux
x86_64 (glibc) builds, where `int64_t` is typedef'd to `long` — there,
`long long` is ambiguous against `(long)` vs `(double)` for the same
reason.
The portable fix is to parse with `std::stoll` (explicit 64-bit,
semantically correct for milliseconds-since-epoch) and
`static_cast<int64_t>` to bind to the integer constructor regardless of
what `int64_t` resolves to on the target platform:
```cpp
request.SetTimestamp(
Aws::Utils::DateTime(static_cast<int64_t>(std::stoll(it->second))));
```
Verified with an overload-resolution mini-repro using the same clang-20
toolchain: only the explicit-cast form is unambiguous on both `int64_t =
long long` (macOS) and `int64_t = long` (Linux x86_64) targets.
---
be/src/load/routine_load/kinesis_conf.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/be/src/load/routine_load/kinesis_conf.cpp
b/be/src/load/routine_load/kinesis_conf.cpp
index 82cf35ea274..0085dd8d374 100644
--- a/be/src/load/routine_load/kinesis_conf.cpp
+++ b/be/src/load/routine_load/kinesis_conf.cpp
@@ -115,7 +115,8 @@ Status KinesisConf::apply_to_get_shard_iterator_request(
it = _get_shard_iterator_params.find("timestamp");
if (it != _get_shard_iterator_params.end()) {
try {
- request.SetTimestamp(Aws::Utils::DateTime(std::stol(it->second)));
+ request.SetTimestamp(
+
Aws::Utils::DateTime(static_cast<int64_t>(std::stoll(it->second))));
} catch (const std::exception&) {
return Status::InternalError("Failed to apply
get_shard_iterator.timestamp: {}",
it->second);
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
