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.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
