You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From implementations for Timestamp and Duration well-known types that convert to standard library std::time::SystemTime and std::time::Duration state that they panic when given values out of the allowed range. However, this is against the contract that From imposes on implementations:
Note: This trait must not fail. The From trait is intended for perfect conversions. If the conversion can fail or is not perfect, use TryFrom.
This contract breakage is especially severe in the case of protobuf crate as Protocol Buffers messages usually contain data from "the outside" and should not be trusted. If the application relies on the fact that From conversion cannot fail (as I usually do), it means that a malformed message can easily bring it down.
The text was updated successfully, but these errors were encountered:
If by "deprecate" we mean "add the #[deprecate] attribute", it won't work: rust-lang/rust#39935. Deprecation is possible only in the "note in the docs" sense—but then it is not that much better than information about the panic, although it paves the way for removing it in the next major release.
Alternatively, the implementations could saturate—instead of panicking (because of the overflow) they could return the largest Duration and SystemTime values possible. The issue here is that there is no SystemTime::MAX defined in the standard library (see rust-lang/rust#71224 for related discussion), although there is Duration::MAX.
From
implementations forTimestamp
andDuration
well-known types that convert to standard librarystd::time::SystemTime
andstd::time::Duration
state that they panic when given values out of the allowed range. However, this is against the contract thatFrom
imposes on implementations:This contract breakage is especially severe in the case of
protobuf
crate as Protocol Buffers messages usually contain data from "the outside" and should not be trusted. If the application relies on the fact thatFrom
conversion cannot fail (as I usually do), it means that a malformed message can easily bring it down.The text was updated successfully, but these errors were encountered: