Wrong float values via `findCustomMessageOption`
See original GitHub issueI ran into a float decoding issue with the output of findCustomMessageOption()
when generating code for float validation rules as defined here:
https://github.com/bufbuild/protoc-gen-validate/blob/main/tests/harness/cases/numbers.proto#L8
The value 1.23
in that float.const
option is turned into 1.2300000190734863
once it reaches my protoplugin code generator here.
As seen here (in the output): https://github.com/fubhy/protobuf-zod/blob/main/packages/protoc-gen-validate-zod/tests/harness/cases/numbers_zod.ts#L47-L51
Is that a known issue or am I doing sth. wrong or is there a bug with that? I can dig deeper myself if nothing comes to mind right away but I thought I’d ask first …
Issue Analytics
- State:
- Created a year ago
- Comments:6 (6 by maintainers)
Top Results From Across the Web
How to handle floats and decimal separators with html5 input ...
I haven't been able to find a way to turn HTML5 validation off. I can turn off or customize the error message, but...
Read more >float | CSS-Tricks
The float property in CSS is used for positioning and layout on web pages. A common usage might be floating an image to...
Read more >float - CSS: Cascading Style Sheets - MDN Web Docs - Mozilla
The float CSS property places an element on the left or right side of its container, allowing text and inline elements to wrap...
Read more >You cannot convert text to number when the cell contains a ...
In the Rules section, make sure the Number stored as text rule is selected, and then click OK. To do this in Microsoft...
Read more >Language Guide | Protocol Buffers - Google Developers
As you can see, each field in the message definition has a unique number. These numbers are used to identify your fields in...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Yeah meant to respond. After some investigation to verify we are parsing these correctly, this actually is expected just by the nature of precision with floating-point in JavaScript. There’s really not much we can do to alleviate it, since it’s part of the language itself.
I guess it boils down to this …
Which, I guess, is expected.