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

[Joel Sherrill]

On 11/25/2013 1:24 AM, Sebastian Huber wrote:
> On 2013-11-22 15:08, Joel Sherrill wrote:
>> 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.
> 
> Two or more pointers of the same type or char * or void * pointers.
> 
> Since all parameters here have distinct pointer types and they don't have char 
> * or void * types the restrict makes no sense here.

OK. I was leaning to backing this off on the simple grounds that
I don't have time to review the rest of the filesystem code but
this is a better reason. :)

>> This one accidentally
>> got propagated down from this as I was being aggressive.
> 
> I would completely remove the restrict from the handlers, they are useless.
> 

OK.

-- 
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