Skip to main content
Associate III
January 16, 2025
Solved

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

  • January 16, 2025
  • 2 replies
  • 1371 views

image.png

The correct declaration should be:
void initialise_monitor_handles( void )

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

Best answer by JVERN.18

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).

2 replies

Andrew Neil
Super User
January 16, 2025

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.
JVERN.18Author
Associate III
January 16, 2025

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...

Andrew Neil
Super User
January 16, 2025

@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.
Associate III
November 18, 2025

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

 

Associate III
November 25, 2025

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