[rtems commit] statvfs and ALL filesystem handlers: Add restrict keyword.
joel.sherrill at OARcorp.com
Mon Nov 25 13:32:50 UTC 2013
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.
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