cancel
Showing results for 
Search instead for 
Did you mean: 

The function initialise_monitor_handles() in syscalls.c is not declared correctly

JVERN.18
Associate III

image.png

The correct declaration should be:
void initialise_monitor_handles( void )

This is not very important... but it generates warnings

1 ACCEPTED SOLUTION

Accepted Solutions

Yes, just adding "void" is enough to make the compiler happy (and me too)... and no, I absolutely do not need this function (void, by the way).

View solution in original post

6 REPLIES 6
Andrew Neil
Super User

Please see the community guidelines for how to properly post source code - not as screenshots:

How to write your question to maximize your chances to find a solution

How to insert source code

 


@JVERN.18 wrote:

it generates warnings


What warnings, exactly?

And what build tools & version are you using?

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

Sorry for the scrrenshots, I'll be more careful next time...

The compiler is LLVM/Clang and the warning is "a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]"

This is not a very important warning, and I see that GNU does not see a problem, but frankly, we're not in the 1980s anymore...


@JVERN.18 wrote:

the warning is "a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]"...


So just changing the declaration to add the 'void' wouldn't fix that warning - you'd still need to add a prototype?

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

Yes, just adding "void" is enough to make the compiler happy (and me too)... and no, I absolutely do not need this function (void, by the way).

JesperEC
Associate III

Dear STMicroelectronics,

May we please ask you to fix the code generator in STM32CubeMX, so that we don't need to fix this line ourselves whenever we regenerate our projects?

Of course we all want to enable many warnings when we build but few of us are running C23 where this would be valid code.

 

I am not sure why the stub is even needed in syscalls.c to begin with?

To my understanding, initialise_monitor_handles() is used when doing debugging with ARM semihosting. And if you are doing that, you need to make sure that this function is doing something useful as part of startup. Wouldn't you want to remove syscalls.c entirely in that case and use the proper specs to get newlib where printf() and friends are redirected to the debugger instead of to the UART?

#Bug-report

   Best regards, Jesper

 

According to How to use semihosting with STM32CubeIDE and STM32 - STMicroelectronics Community you are supposed to delete the generated syscalls.c when enabling semihosting and this is indeed necessary to avoid linking failing due to multiple symbol definitions when linking to librdimon. Following the instructions will give you the initialise_monitor_handles() from librdimon_nano.a(arm_librdimon_a-syscalls.o).

So the function is truly redundant in syscalls.c.

The only reason to have it there would be to be able to leave the call to initialise_monitor_handles() in main() for all builds without getting linking failures for the non-semihosting build. Given that you anyway have to modify (delete) syscalls.c to not clash with other syscall implementations that newlib needs and that are provided by librdimon - such as _close, _getpid, … this doesn't seem useful. And there is no call to initialise_monitor_handles()  in the main.c normally generated by STM32CubeMX. If a developer adds it, he should also add the nop-stub if needed.

    Best regards, Jesper