Hello Sebastian,
On 2/8/21 7:54 AM, Sebastian Huber wrote:
> On 14/12/2020 09:44, Sebastian Huber wrote:
>
>> Change RTEMS_STRING() and RTEMS_XSTRING() to accept a variable number of
>> arguments which is stringified. This can be used for example to create
>> register lists for inline assembler statements.
>> ---
>> cpukit/include/rtems/score/basedefs.h | 16 ++++++++--------
>> 1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/cpukit/include/rtems/score/basedefs.h
>> b/cpukit/include/rtems/score/basedefs.h
>> index 0081dbfbe4..87a693e180 100644
>> --- a/cpukit/include/rtems/score/basedefs.h
>> +++ b/cpukit/include/rtems/score/basedefs.h
>> @@ -335,13 +335,13 @@ extern "C" {
>> /**
>> * @ingroup RTEMSAPIBaseDefs
>> *
>> - * @brief Stringifies _x without expanding.
>> + * @brief Stringifies the arguments without expanding them.
>> *
>> - * @param _x is the token to stringify.
>> + * @param ... are the arguments to stringify.
>> *
>> - * @return Returns the stringification of the token _x.
>> + * @return Returns the stringification of the arguments.
>> */
>> -#define RTEMS_STRING( _x ) #_x
>> +#define RTEMS_STRING( ... ) #__VA_ARGS__
>> /* Generated from spec:/rtems/basedefs/if/typeof-refx */
>> @@ -898,13 +898,13 @@ extern "C" {
>> /**
>> * @ingroup RTEMSAPIBaseDefs
>> *
>> - * @brief Stringifies the expansion of _x.
>> + * @brief Stringifies the expansion of the arguments.
>> *
>> - * @param _x is the token expand and stringify.
>> + * @param ... are the arguments to expand and stringify.
>> *
>> - * @return Returns the stringification of the expansion of token _x.
>> + * @return Returns the stringification of the expansion of the
>> arguments.
>> */
>> -#define RTEMS_XSTRING( _x ) RTEMS_STRING( _x )
>> +#define RTEMS_XSTRING( ... ) RTEMS_STRING( __VA_ARGS__ )
>> /* Generated from spec:/rtems/basedefs/if/define-global-symbol */
> Any objections to push this? It makes the macro a bit more flexible.
> Linux uses the same approach.
No objections but I am missing something. We do not used a certain
frozen RTEMS version for the pre-qualification, do we?
This brings about the problem that very change in RTEMS which is part of
the pre-qualified source code must trigger the needed changes in the
pre-qualification data set - here in the specification items:
spec/rtems/basedefs/req/string-0.yml
spec/rtems/basedefs/req/xstring-0.yml
I know, everyone wants to program and push his/her code into RTEMS as
fast as possible without dealing with documentation, specification items
or other depending stuff. ... and I am among the first doing so ...
Yet, if the pre-qualification data set is not continuously kept up to
date, the whole documentation is outdated even before the
pre-qualification project ends. Is this topic somehow addressed? ... and
who is responsible to adapt the above two files?
Greetings
fk
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
