Skip to content
Snippets Groups Projects
Select Git revision
  • 7e7d571845464e26084632e5e8b2fe0c5c6dc787
  • main default protected
  • release-2025-06-11-with-patches protected
  • release-2025-05-15-with-patches protected
  • release-2025-03-27-with-patches protected
  • release-2024-12-30-with-client-builder protected
  • release-2024-12-26-with-client-builder protected
  • release-2024-11-05-with-client-builder protected
  • release-2024-08-16-with-client-builder protected
  • release-2024-09-09-with-client-builder protected
  • release-2024-08-28-with-client-builder protected
  • release-2024-10-09-with-client-builder protected
  • sbuttgereit/expose_client_builder_with_hyper_1_0
  • release-2025-06-11
  • release-2025-06-03
  • release-2025-05-19
  • release-2025-05-15
  • release-2025-05-09
  • release-2025-05-02
  • release-2025-04-23
  • release-2025-03-27
  • release-2025-03-25
  • release-2025-03-10
  • release-2025-03-04
  • release-2025-02-20
  • release-2025-02-12
  • release-2025-02-03
  • release-2025-01-28
  • release-2025-01-23
  • release-2025-01-17
  • release-2025-01-14
  • release-2024-12-30
  • release-2024-12-26
33 results

smithy-rs

user avatar
david-perez authored
Currently, conversions from `aws_smithy_types::Number` into numeric Rust
types (`{i,u}{8, 16, 32, 64}` and `f{32, 64}`) are always lossy, because
they use the `as` Rust keyword to cast into the target type. This means
that clients and servers are accepting lossy data: for example, if an
operation is modeled to take in a 32-bit integer as input, and a client
incorrectly sends an integer number that does not fit in 32 bits, the
server will silently accept the truncated input. There are malformed
request protocol tests that verify that servers must reject these
requests.

This commit removes the lossy `to_*` methods on `Number` and instead
implements `TryFrom<$typ> for Number` for the target numeric type
`$typ`. These converters will attempt their best to perform the
conversion safely, and fail if it is lossy.

The code-generated JSON parsers will now fail with
`aws_smithy_json::deserialize::ErrorReason::InvalidNumber` if the number
in the JSON document cannot be converted into the modeled integer type
without losing precision. For floating point target types, lossy
conversions are still performed, via `Number::to_f32_lossy` and
`Number::to_f64_lossy`.
7e7d5718
History
Name Last commit Last update