There is no need to pass any extra parameters to such function
- for Ada code, all you need is to play with Ada.Command_Line
- for C code, all you need in the main() function is to copy argc argv into some global constants (symbols) exported, then any C function can use it.

So impact on the whole toolchain can be absolutely limited to zero, only for C a modification to po_hi_main.c to populate the corresponding symbols

Ok - your solution is indeed simpler. However using Ada.Command_Line is not wise, since it is depending on using the Ada runtime.

Your second point should be the rule for both Ada and C runtimes : export a global constant that both Ada and C can see.

The Ada runtime can be used in both setups: either Ada or C OS, the only restriction is on tasking itself;
but of course we can have argc/argv also for Ada

for the records, a UK-based company involved in ASSERT used this trick to configure its SpaceWire fake driver for tsim ;)

So can we agree on the two following globals:

int __argc;
char *__argv[];

Julien, can you set it when the main is in C,
Jérôme can you :

1) set it when the main is in Ada (including Pragma Export for C)
2) give the Pragma import syntax to use when the main is in C to access it from an Ada function

Only for native platforms

Wait guys, I think we go in the wrong direction. Using the command-line parameters is a really bad idea. Why ? Because only native machines use that and embedded system does not. In addition, by using this, we rely on string and so, would introduce string-management function that are most of the time forbidden due to indeterminism and other reasons.

At this point, I am just wondering what are the real need for that and what is the rationale. Can you provide an example for such a feature ?

As I said, it is only for native applications, not embedded/real-time ones.

The objective is to allow a new range of applications that can receive configuration parameters, flags, etc, as it is typical for command-line applications. Given the ease of implementing such feature I think we should not restrain ourselves from getting it.

BTW, you are doing string parsing at runtime in the current implementation of the driver configuration - I have been fighting against you for a year about that, so the argument is not accepted :-)

Jerome: I looked at what you proposed but the main() is not defined in po_hi_main.c, it is generated in main.c by Ocarina, and it is defined like that:
__PO_HI_MAIN_TYPE __PO_HI_MAIN_NAME (void)

These macros are defined in po_hi_task.h:

#if defined(POSIX) || defined (XENO_POSIX)

#define __PO_HI_MAIN_NAME main
#define __PO_HI_MAIN_TYPE int
#define __PO_HI_MAIN_ARGS int argc , char *argv[] , char **arge

(And they are different for each platform)

There are two issues:
1) Why is the __PO_HI_MAIN_ARGS not generated in main.c?
2) We cannot generate the copy to a global variable unless we add another #if defined(POSIX)... in the generated main.c

Even if we don't implement the copy to a global variable in C, I think it would still be good to fix the bug reported:

main.c (generated by ocarina) contains:

__PO_HI_MAIN_TYPE __PO_HI_MAIN_NAME (void)

while it should contain (I think):

__PO_HI_MAIN_TYPE __PO_HI_MAIN_NAME (__PO_HI_MAIN_ARGS)

@Jerome : was this fixed?