Notes |
|
(0000227)
|
hugues
|
2011-01-12 11:09
|
|
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 |
|
|
(0000233)
|
maxime
|
2011-01-12 12:43
|
|
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. |
|
|
(0000234)
|
hugues
|
2011-01-12 12:47
|
|
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 ;) |
|
|
(0000241)
|
maxime
|
2011-01-12 13:11
|
|
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 |
|
|
(0000243)
|
user2
|
2011-01-12 13:21
|
|
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 ? |
|
|
(0000244)
|
maxime
|
2011-01-12 15:06
|
|
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 :-) |
|
|
(0002223)
|
maxime
|
2014-11-27 13:40
(edited on: 2016-01-27 13:39) |
|
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
|
|
|
(0003245)
|
maxime
|
2018-02-16 17:15
|
|
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)
|
|
|
(0003780)
|
maxime
|
2021-05-21 10:06
|
|
@Jerome : was this fixed? |
|