-
Notifications
You must be signed in to change notification settings - Fork 52
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
Error while parsing Int32 #67
Comments
Hi @daappWork, I can confirm that it's easy to reproduce issue: Prelude Data.Int> 50674208269 :: Int32
<interactive>:8:1: warning: [-Woverflowed-literals]
Literal 50674208269 is out of the Int32 range -2147483648..2147483647
-865399283 |
Hmmm, github automatically closed the issue. |
Issue appeared again on HEAD but for
|
Released on Hackage: https://hackage.haskell.org/package/telegram-bot-simple-0.4 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I use version 0.3.4.
I've got this in my bot:
DecodeFailure "Error in $.result[0].message.from.id: parsing Int32 failed, value is eithe
r floating or will cause over or underflow 5.067420826e9" (Response {responseStatusCode = Status {statusCode = 200, statusMessage = "OK"}, response
Headers = fromList [("Server","nginx/1.18.0"),("Date","Mon, 20 Dec 2021 13:21:11 GMT"),("Content-Type","application/json"),("Content-Length","399")
,("Connection","keep-alive"),("Strict-Transport-Security","max-age=31536000; includeSubDomains; preload"),("Access-Control-Allow-Origin","*"),("Acc
ess-Control-Allow-Methods","GET, POST, OPTIONS"),("Access-Control-Expose-Headers","Content-Length,Content-Type,Date,Server,Connection")], responseH
ttpVersion = HTTP/1.1, responseBody = "{"ok":true,"result":[{"update_id":68483329,\n"message":{"message_id":27943,"from":{"id":5067420826,
Looks like last number in fragment parsed incorrectly.
From telegram bot api:
Unique identifier for this user or bot. This number may have more than 32 significant bits and some programming languages may have difficulty/silent defects in interpreting it. But it has at most 52 significant bits, so a 64-bit integer or double-precision float type are safe for storing this identifier.
I have read changes up to 0.3.8 and find no fix for this.
The text was updated successfully, but these errors were encountered: