arruah
Hello everyone,
I’m encountering a truly baffling and persistent issue with Elixir’s bitstring syntax for little-endian integer encoding, and I’m hoping someone here might have seen something similar or can
shed some light on it.
The Problem: When attempting to convert a specific 32-bit unsigned integer (1749397227) to its little-endian binary representation, both the direct bitstring syntax
(<integer::unsigned-little-integer-size(32)>) and Erlang’s :binary.encode_unsigned(:little) function produce an incorrect byte order on my system.
• The integer 1749397227 in hexadecimal is 0x6874462B.
• Its correct Little-Endian binary representation should be <<0x2B, 0x46, 0x74, 0x68>>, which is “2B467468” in hex.
However, my system consistently produces <<0xEB, 0xAE, 0x45, 0x68>>, which is “EBAE4568” in hex.
Minimal iex Reproduction:
Please run these lines in your iex session and share the output:
my_int = 1749397227
le_bin = <<my_int::unsigned-little-integer-size(32)>>
expected_hex = "2B467468"
actual_hex = Base.encode16(le_bin)
IO.puts("--- Bitstring Test ---")
IO.puts("Integer: #{my_int}")
IO.puts("Expected LE: #{expected_hex}")
IO.puts("Actual LE: #{actual_hex}")
IO.puts("Match: #{actual_hex == expected_hex}")
# Also test Erlang's :binary module
erlang_le_bin = :binary.encode_unsigned(my_int, :little)
erlang_actual_hex = Base.encode16(erlang_le_bin)
IO.puts("\n--- Erlang :binary Test ---")
IO.puts("Expected LE: #{expected_hex}")
IO.puts("Actual LE: #{erlang_actual_hex}")
IO.puts("Match: #{erlang_actual_hex == expected_hex}")
My Observed Output (consistently):
— Bitstring Test —
Integer: 1749397227
Expected LE: 2B467468
Actual LE: EBAE4568
Match: false
— Erlang :binary Test —
Expected LE: 2B467468
Actual LE: EBAE4568
Match: false
Troubleshooting Steps Taken (Extensive):
1 Confirmed source code (lib/util/crypto.ex) uses the correct bitstring syntax.
2 Confirmed manual bitwise operations (<<val &&& 0xFF, …>>) do produce the correct “2B467468” when run directly in iex.
3 Performed multiple mix clean --all and rm -rf _build deps priv/repo/migrations.
4 Performed a complete reinstallation of Elixir and Erlang/OTP using asdf (uninstalling, clearing ~/.asdf/downloads and build caches, then reinstalling stable Erlang 27.0 and Elixir
1.18.3-otp-27).
5 Confirmed elixir --version shows the newly installed versions.
6 Ran mix test and direct function calls in iex -S mix after each step.
Despite all this, the issue persists. This suggests a very deep environmental problem.
My System Information:
• elixir --version output: (Paste your actual output here, e.g., Erlang/OTP 27 [erts-15.2.3] … Elixir 1.18.3 (compiled with Erlang/OTP 27))
• Operating System: (e.g., Ubuntu 22.04 LTS)
• CPU Architecture: (e.g., x86_64, ARM64)
Has anyone ever encountered such a fundamental and persistent issue with bitstring encoding in Elixir/Erlang? Any insights or further diagnostic steps would be greatly appreciated!
Thank you!
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixir-ls
- #elixirconf-us
- #ai
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming










Showing Posts 1 to 4- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
aviagarwal1212
Could you explain why you expect the output to be 2B467468? I tried to confirm through javascript,
Integer: 1749397227
Big-Endian Binary: 01101000 01000101 10101110 11101011
Little-Endian Binary: 11101011 10101110 01000101 01101000
Hex: EBAE4568
adamu
Are you using AI by any chance?
This is not true. 1749397227 in hexadecimal is 0x6845AEEB.
arruah
Sorry, It looks like my AI fooled me.
adamu
At least we identified the deep environmental problem