Check return code of fwrite in raw image writing code.

Check return code of fwrite in raw image writing code.

Change-Id: I8c52a205ae1dc559c9f8b41d4d2c50e821b3b05c

BUG=None
TEST=None

Committed: http://chrome-svn/viewvc/chromeos?view=rev&revision=7cdc68c

[Micah C, 2011-02-08 03:52:46]

A few nits.  What's the larger context for this change?  Is there a bug number
that can be linked?  I don't see any call sites for the affected function (in
this CL) so not sure what the side-effects of the change will be.

http://codereview.chromium.org/6368153/diff/1/data_layout.c
File data_layout.c (right):

http://codereview.chromium.org/6368153/diff/1/data_layout.c#newcode1020
data_layout.c:1020: {
What is the need for this extra indentation and enclosing braces?

http://codereview.chromium.org/6368153/diff/1/data_layout.c#newcode1021
data_layout.c:1021: size_t	bytes = pages_to_write * context->page_size;
The \t after size_t bytes might be replaceable with a space to be consistent
with the rest of the file.

http://codereview.chromium.org/6368153/diff/1/data_layout.c#newcode1024
data_layout.c:1024: return -1;
Another error exit from this function returns a negative symbolic constant
(-ENOMEM).  Is there an appropriately named error return value that fits this
path better than -1?  What does the caller of write_block_raw() expect?

[robotboy, 2011-02-08 18:48:00]

Done, and questions answered, PTAL.

http://codereview.chromium.org/6368153/diff/1/data_layout.c
File data_layout.c (right):

http://codereview.chromium.org/6368153/diff/1/data_layout.c#newcode1020
data_layout.c:1020: {
ANSI C doesn't allow for the declaration of a variable anywhere but at the
beginning of a block.  I did it this way because the bytes variable is not
needed anywhere outside this block and it localized the change.

http://codereview.chromium.org/6368153/diff/1/data_layout.c#newcode1021
data_layout.c:1021: size_t	bytes = pages_to_write * context->page_size;
On 2011/02/08 03:52:46, Micah C wrote:
> The \t after size_t bytes might be replaceable with a space to be consistent
> with the rest of the file.

Done.

http://codereview.chromium.org/6368153/diff/1/data_layout.c#newcode1024
data_layout.c:1024: return -1;
I believe that the correct thing to do is check both feof() and ferror() upon
seeing a smaller count than was requested to be written returned.  Then an
appropriate error code can be determined and returned.  In this case the caller
of write_block_raw is just checking that the return code is != 0 and if it is
(not equal to zero) then it prints a generic failure message.

[micahc, 2011-02-10 18:27:54]

LGTM as is, thanks for explanation.

If there is any other symbolic constant for an "unspecified error" other than
-1, you might swap that in -- but don't spend much time looking for one.