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

[Sebastian Huber]

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.

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

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.