[rtems commit] statvfs and ALL filesystem handlers: Add restrict keyword.

Joel Sherrill joel.sherrill at OARcorp.com
Fri Nov 22 14:08:11 UTC 2013

On 11/22/2013 1:55 AM, Sebastian Huber wrote:
> On 2013-11-21 23:50, Joel Sherrill wrote:
>> diff --git a/cpukit/libcsupport/include/rtems/libio.h b/cpukit/libcsupport/include/rtems/libio.h
>> index 21d57eb..c1b7b73 100644
>> --- a/cpukit/libcsupport/include/rtems/libio.h
>> +++ b/cpukit/libcsupport/include/rtems/libio.h
>> @@ -485,8 +485,8 @@ typedef int (*rtems_filesystem_rename_t)(
>>    * @see rtems_filesystem_default_statvfs().
>>    */
>>   typedef int (*rtems_filesystem_statvfs_t)(
>> -  const rtems_filesystem_location_info_t *loc,
>> -  struct statvfs *buf
>> +  const rtems_filesystem_location_info_t *__restrict loc,
> Why do we have now the __restrict for the "loc" parameter?  Provided it is 
> justified to use it here, why only in this handler?

The restrict keyword only makes sense on calls
which take two pointer parameters.  This one accidentally
got propagated down from this as I was being aggressive.

int statvfs(const char *restrict, struct statvfs *restrict);

But thinking about it, all file system methods
shouldn't have loc the same as any other pointer

What do you think about all file system plugin points
having restrict for loc versus buffers or whatever user
parameters are passed in?

The user parameters themselves follow the APIs above.

>> +  struct statvfs *__restrict buf
>>   );
>>   /**

Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

More information about the devel mailing list