I am reverting this back to an appropriate comment and (void) on the return values.
fsync_h on the IMFS is set to the default handler which is rtems_filesystem_default_fsync_or_fdatasync(). It is a one line method that returns EINVAL. I can either throw away the _Assert's or make them more complicated. That seems worse. My plan is to go back to (void), update the comment, and if this shows up again in ANY static analyser, we should mark it as intentional and ignore. --joel On 11/27/2014 10:07 AM, Joel Sherril wrote:
Module: rtems Branch: master Commit: e22af784cd44cd407e268307ede01f6e1b621393 Changeset: http://git.rtems.org/rtems/commit/?id=e22af784cd44cd407e268307ede01f6e1b621393 Author: Joel Sherrill<joel.sherr...@oarcorp.com> Date: Thu Nov 27 09:30:12 2014 -0600 sync.c: Add asserts to document and check assumptions --- cpukit/libcsupport/src/sync.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/cpukit/libcsupport/src/sync.c b/cpukit/libcsupport/src/sync.c index 653a177..f27349c 100644 --- a/cpukit/libcsupport/src/sync.c +++ b/cpukit/libcsupport/src/sync.c @@ -29,6 +29,7 @@ int fdatasync(int); /* still not always prototyped */ #include<stdio.h> #include<rtems.h> +#include<rtems/score/assert.h> /* XXX check standards -- Linux version appears to be void */ void _fwalk(struct _reent *, void *); @@ -37,14 +38,19 @@ void _fwalk(struct _reent *, void *); static void sync_wrapper(FILE *f) { int fn = fileno(f); + int rc; /* - * We are explicitly NOT checking the return values as it does not - * matter if they succeed. We are just making a best faith attempt - * at both and trusting that we were passed a good FILE pointer. + * We are explicitly NOT checking the return values in non-debug builds + * as it does not matter if they succeed. We are just making a best + * faith attempt at both and trusting that we were passed a good + * FILE pointer. */ - fsync(fn); - fdatasync(fn); + rc = fsync(fn); + _Assert( rc == 0 ); + + rc = fdatasync(fn); + _Assert( rc == 0 ); } /* iterate over all FILE *'s for this thread */ _______________________________________________ vc mailing list v...@rtems.org http://lists.rtems.org/mailman/listinfo/vc
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
