[PATCH] basedefs: Add stringification of argument lists

[Frank Kühndel]

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