# Snprintf() not handling %lli or %llu for int64\_t and uint64\_t respectively **URL:** \ **Category:** Firmware\ **Tags:** photon\ **Created:** [December 30, 2020, 1:03pm UTC](https://community.particle.io/t/snprintf-not-handling-lli-or-llu-for-int64-t-and-uint64-t-respectively/58918 "2020-12-30T13:03:50Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![armor](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/armor/32/18398_2.png) [@armor](https://community.particle.io/u/armor)\ **Post date:** [December 30, 2020, 1:03pm UTC](https://community.particle.io/t/snprintf-not-handling-lli-or-llu-for-int64-t-and-uint64-t-respectively/58918/1 "2020-12-30T13:03:50Z")
I am trying to handle a 7 byte Desfire card UID. Things have been fine using a uint32\_t variable to hold and display the 4 byte MiFare card UID. I thought I would use uint64\_t instead of uint32\_t - unfortunately snprintf() does not appear to handle C format conversion specifier %llu - output is “lu” and a string terminator. Any ideas what I am missing? Thanks ---
**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\ **Post date:** [December 30, 2020, 1:26pm UTC](https://community.particle.io/t/snprintf-not-handling-lli-or-llu-for-int64-t-and-uint64-t-respectively/58918/2 "2020-12-30T13:26:45Z")
I guess this statement from 2016 is still valid > [@Problems when using long long](https://community.particle.io/t/problems-when-using-long-long/19302/18): > > The trap is that not all C runtime functions are equipped to deal with 64-bits, sprintf being one example. ---
**Author:** ![armor](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/armor/32/18398_2.png) [@armor](https://community.particle.io/u/armor)\ **Post date:** [December 30, 2020, 1:47pm UTC](https://community.particle.io/t/snprintf-not-handling-lli-or-llu-for-int64-t-and-uint64-t-respectively/58918/3 "2020-12-30T13:47:46Z")
@ScruffR Thanks for the quick response - I picked this out from mdma - My guess is that the sprintf is not handling the 64-bit datatype. `%lld` To print, I see you have 2 options: 1. write your own routine to print the long long value 2. convert to double and print using sprintf Not sure how to do 1. would you know where to start? 2. I understand. I wonder if there is a library that can be included to support this - also printf() doesn’t work either. ---
**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\ **Post date:** [December 30, 2020, 1:51pm UTC](https://community.particle.io/t/snprintf-not-handling-lli-or-llu-for-int64-t-and-uint64-t-respectively/58918/4 "2020-12-30T13:51:12Z")
My take would be to go HEX - with that you can take each individual byte as is whether you have 1, 2, 4 or 8 doesn’t matter 😉 ---
**Author:** ![rickkas7](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/rickkas7/32/8681_2.png) [@rickkas7](https://community.particle.io/u/rickkas7)\ **Post date:** [December 30, 2020, 1:57pm UTC](https://community.particle.io/t/snprintf-not-handling-lli-or-llu-for-int64-t-and-uint64-t-respectively/58918/5 "2020-12-30T13:57:02Z")
It’s [a documented limitation](https://docs.particle.io/reference/device-os/firmware/argon/#sprintf). As a workaround you can use the `Print64` firmware library in the community libraries. The source and instructions can be found [in Github](https://github.com/rickkas7/Print64/). ---
**Author:** ![armor](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/armor/32/18398_2.png) [@armor](https://community.particle.io/u/armor)\ **Post date:** [December 30, 2020, 4:52pm UTC](https://community.particle.io/t/snprintf-not-handling-lli-or-llu-for-int64-t-and-uint64-t-respectively/58918/6 "2020-12-30T16:52:15Z")
@rickkas7 @ScruffR Thanks both - and for writing a function to manage this. ---
**Author:** ![UMD](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/umd/32/5850_2.png) [@UMD](https://community.particle.io/u/UMD)\ **Post date:** [January 2, 2021, 10:11pm UTC](https://community.particle.io/t/snprintf-not-handling-lli-or-llu-for-int64-t-and-uint64-t-respectively/58918/7 "2021-01-02T22:11:52Z")
@armor, why do you need to convert to decimal at all? ---
**Author:** ![armor](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/armor/32/18398_2.png) [@armor](https://community.particle.io/u/armor)\ **Post date:** [January 3, 2021, 10:06am UTC](https://community.particle.io/t/snprintf-not-handling-lli-or-llu-for-int64-t-and-uint64-t-respectively/58918/8 "2021-01-03T10:06:46Z")
@UMD Good question - the answer is space. I am using backup (retained) RAM (with battery backup) so I am limited to 3K on the Photon. The reason for using backup RAM is that I can search using simple search. Inefficient but still quick enough for my needs, space then becomes the constraint. The tag reader outputs a card serial number or UID of either 4 bytes or 7 bytes length. The first, 4 bytes can be stored in a uint32\_t with a value of 0-4294967295 that’s 10 chars and if stored as a c-string with null terminator 11 chars - so 7 bytes per entry bigger. When formatting to receive via a command I can use strtoul() and c format printf using %lu. The second, 7 bytes can be stored in uint64\_t with a value of 0-72057594037927935 that’s 17 chars and 18 chars with null terminator or 10 bytes more. I appreciate that BCD could be used but then there is the further translation and it still takes more room. As discussed earlier in the topic the printf format is a problem for uint64\_t - now solved and strtoull() works. ---
**Author:** ![UMD](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/umd/32/5850_2.png) [@UMD](https://community.particle.io/u/UMD)\ **Post date:** [January 3, 2021, 11:31am UTC](https://community.particle.io/t/snprintf-not-handling-lli-or-llu-for-int64-t-and-uint64-t-respectively/58918/9 "2021-01-03T11:31:39Z")
@armor, given that the natural data format for 99.999% of computers in the world is binary, the most efficient space utilisation will be to _not_ convert from binary to decimal. You said: > 7 bytes can be stored in uint64\_t uint64\_t takes 8 bytes, so the effort of converting to decimal means that you are using one byte more. uint32\_t for the 4 byte UID conversion takes the same amount of space. To display the UID, you could use something like the following to fill the string buffer with ASCII hexadecimal representation of the UID for the human (other methods can be envisaged of course): ```auto sprintf(buf, "%02X%02X%02X%02X%02X%02X%02X", uid[0], uid[1], uid[2], uid[3], uid[4], uid[5], uid[6]); ``` So, an 7 byte NFC tag UID of 0x044A7232214B80 would be displayed as 14 ASCII digits: "044A7232214B80". Re efficient searching, a simple iteration through the data will be **really quick** , so no need to worry about that as an issue. Schemes can be envisage to handle the data structure of 4 byte vs 7 byte UID's. In short, - store the UID's in their raw binary form - search by iterating the structure through memory - convert to the binary to ASCII hexadecimal for the human Hope this helps. ---
**Author:** ![armor](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/armor/32/18398_2.png) [@armor](https://community.particle.io/u/armor)\ **Post date:** [January 3, 2021, 5:59pm UTC](https://community.particle.io/t/snprintf-not-handling-lli-or-llu-for-int64-t-and-uint64-t-respectively/58918/10 "2021-01-03T17:59:49Z")
> [@UMD](#): > > convert to the binary to ASCII hexadecimal for the human I don't disagree with anything you are saying except that normal people do not use hexadecimal! The other aspect is that using uint64\_t and uint32\_t means I don't have to create a special data type and I can very easily implement 7 byte UID support once 4 byte UID support is implemented - yes I would save 1 byte but there again most storage schemes round to the nearest word (4 bytes). ---
**Author:** ![system](https://us1.discourse-cdn.com/flex026/uploads/particle/original/3X/6/4/64635adccc35238caa19e9b553ec3e98b163d026.png) [@system](https://community.particle.io/u/system)\ **Post date:** [July 5, 2021, 5:59am UTC](https://community.particle.io/t/snprintf-not-handling-lli-or-llu-for-int64-t-and-uint64-t-respectively/58918/11 "2021-07-05T05:59:53Z")
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.