RTOS/AM5728: Long long format does not print

The RTOS team have been notified. They will respond here.

Hi,

I am not sure how do code looks like, this is a compiler question. I tried below:

#if 1

   char buffer [50];

   long long a=5000ll;

   unsigned int n;

   n=sprintf (buffer, "%ld \n", a);

#endif

I have no issue:

Building file: "../main.c"
Invoking: GNU Compiler
"C:/ti/gcc-arm-none-eabi-6-2017-q1-update/bin/arm-none-eabi-gcc.exe" -c -mcpu=cortex-a15 -mtune=cortex-a15 -marm -mfloat-abi=hard -Dam5728 -Dcore0 -DevmAM572x -DSOC_AM572x -Dgcc -I"C:/ti/pdk_am57xx_1_0_11/packages/ti/drv/usb" -I"C:/ti/gcc-arm-none-eabi-6-2017-q1-update/arm-none-eabi/include" -g -gdwarf-3 -gstrict-dwarf -Wall -MMD -MP -MF"main.d" -MT"main.o" @"configPkg/compiler.opt" -o"main.o" "../main.c"
../main.c: In function 'main':
../main.c:82:27: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'long long int' [-Wformat=]
n=sprintf (buffer, "%ld \n", a);
^
../main.c:81:18: warning: variable 'n' set but not used [-Wunused-but-set-variable]
unsigned int n;
^
Finished building: "../main.c"

If I use:

n=sprintf (buffer, "%lld \n", a); I saw the issue just "ld" printed. So please use %ld instead.

Regards, Eric

Hi Eric,

Please try it with a number larger than 32 bit.

Thanks

Rasty

Part Number: AM5728

Tool/software: TI-RTOS

Hi,

We  got similar problem undefined __sf_fake_stderr,  __sf_fake_stdin, __sf_fake_stdout is we remove nano.specs from linker.

How issue e2e.ti.com/.../607830  was solved?

Thanks

The post you refer is one year old, and for a completely different processor. Please describe your problem in details. Refer to processors.wiki.ti.com/.../Checklist_for_Processor_SDK_RTOS_questions_on_E2E for the information we need.

Hello Eric,

It didn't work for me,

I have tried the following code, but i get an incorrect values for long long:

  char buffer1 [50];

  char buffer2 [50];

  long long a = 123456789999ll;

  long b = 123456789l;

  unsigned int n1, n2;

  n1=sprintf (buffer1, "%ld \n", a);

  n2=sprintf (buffer2, "%d \n", b);

sprintf - long long:

sprintf long:

please advise,

Sergei Pilipenko

Hi,

I tired what you did, with sprintf with %ld" and got the same results. Let me check with my colleague in compiler team.

Regards, Eric

Oh wait, here is a better description of newlib-nano.  It says ...

support only conversion specifiers defined in C89 standard

C89 is a much older standard for the C programming language and library.  The %lld conversion is not present in C89.

Thanks and regards,

-George

Suggestion will not work for me, because if I use nano.specs I return to original problem %lld does not print.

OK. Let's approach it from different direction.

if I remove nano.specs I get linker errors described here 

:

please do not suggest adding  " --specs=nano.specs" to select 'newlib-nano' as the C runtime library as describer here  :-)  :-)

Thanks

Rasty

George,

All of the TI Processor SDK RTOS AM57x examples are built with "--specs=nano.specs", so the newlib-nano will be linked with this. As you mentioned, newlib-nano supports only conversion specifiers defined in C89 standard, which is a much older standard for the C programming language and library. The %lld conversion is not present in C89.

As Rasty described, if we remove the "--specs=nano.specs", we got error like below:
C:/ti/bios_6_52_00_12/packages/ti/sysbios/rts/gnu/ReentSupport.c:173: undefined reference to `__sf_fake_stdin'
C:/ti/bios_6_52_00_12/packages/ti/sysbios/rts/gnu/ReentSupport.c:173: undefined reference to `__sf_fake_stdout'
C:/ti/bios_6_52_00_12/packages/ti/sysbios/rts/gnu/ReentSupport.c:173: undefined reference to `__sf_fake_stderr'
C:/ti/bios_6_52_00_12/packages/ti/sysbios/rts/gnu/ReentSupport.c:173: undefined reference to `__sf_fake_stdin'
C:/ti/bios_6_52_00_12/packages/ti/sysbios/rts/gnu/ReentSupport.c:173: undefined reference to `__sf_fake_stdout'
C:/ti/bios_6_52_00_12/packages/ti/sysbios/rts/gnu/ReentSupport.c:173: undefined reference to `__sf_fake_stderr'

Is there a way to rebuild the newlib-nano with lld% support? Or how to resolve the RTS error above to support %lld?

Regards, Eric

Rasty,

Let's use e2e.ti.com/.../718820 for tracking this issue.

Regards, Eric

Hi George

I realized that that would be the answer and did what you suggest.

Namely, converting string to "long long" and vice versa.

We use vary basic formatting and it is sufficient for us. 

Hope to find %lld in some future release.

Thanks

Rasty