Skip to content

Fix encoding & decoding large unsigned u32 & u16 ints in MSSQL. #15

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from

Conversation

saltymango2619
Copy link

Fixes #14.

As it stands now, it will still die when trying to decode a super big i64 that's trying to be reinterpreted as a u64. Since MSSQL doesn't really have unsigned types, I don't care about that edge case personally, I'm just going to leave it as that.

If someone really wants it, I guess they can just copy the Decode implementation for i64 and swap out the primitive when calling from_le_bytes.

Ok(i64::from_le_bytes(buf))

@lovasoa
Copy link
Collaborator

lovasoa commented May 21, 2025

I'm sorry, but the current behavior seems correct to me.

Silently ignoring integer conversion errors sounds like a dangerous behavior to introduce. People would end up handling corrupted data without realizing it.

You're right that the current conversion path (going through i32 before u32) may be unnecessarily complex.

The current TryFrom-based implementation is designed to catch exactly these mismatches. If the database column can contain negative values, mapping it to a u32 in Rust is likely incorrect and should be reconsidered—either by using a signed type like i32, or by filtering/validating the data upstream.

@lovasoa lovasoa closed this May 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Can't decode as large u32
2 participants