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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
