[U-Boot] [PATCH] bmp_logo: Check return value of fread()
Add basic error handling to fread() function calls. This prevents compililation warnings such as:
bmp_logo.c: In function ‘main’: bmp_logo.c:71: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result ...
Signed-off-by: Peter Tyser ptyser@xes-inc.com --- tools/bmp_logo.c | 35 ++++++++++++++++++++++------------- 1 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/tools/bmp_logo.c b/tools/bmp_logo.c index 98be617..e8dd8c8 100644 --- a/tools/bmp_logo.c +++ b/tools/bmp_logo.c @@ -40,6 +40,16 @@ void skip_bytes (FILE *fp, int n) fgetc (fp); }
+__attribute__ ((__noreturn__)) +int error (char * msg, FILE *fp) +{ + fprintf (stderr, "ERROR: %s\n", msg); + + fclose (fp); + + exit (EXIT_FAILURE); +} + int main (int argc, char *argv[]) { int i, x; @@ -58,23 +68,25 @@ int main (int argc, char *argv[]) exit (EXIT_FAILURE); }
- if (fgetc (fp) != 'B' || fgetc (fp) != 'M') { - fprintf (stderr, "%s is not a bitmap file.\n", argv[1]); - exit (EXIT_FAILURE); - } + if (fgetc (fp) != 'B' || fgetc (fp) != 'M') + error ("Input file is not a bitmap", fp);
/* * read width and height of the image, and the number of colors used; * ignore the rest */ skip_bytes (fp, 8); - fread (&data_offset, sizeof (uint16_t), 1, fp); + if (fread (&data_offset, sizeof (uint16_t), 1, fp) != 1) + error ("Couldn't read bitmap data offset", fp); skip_bytes (fp, 6); - fread (&b->width, sizeof (uint16_t), 1, fp); + if (fread (&b->width, sizeof (uint16_t), 1, fp) != 1) + error ("Couldn't read bitmap width", fp); skip_bytes (fp, 2); - fread (&b->height, sizeof (uint16_t), 1, fp); + if (fread (&b->height, sizeof (uint16_t), 1, fp) != 1) + error ("Couldn't read bitmap height", fp); skip_bytes (fp, 22); - fread (&n_colors, sizeof (uint16_t), 1, fp); + if (fread (&n_colors, sizeof (uint16_t), 1, fp) != 1) + error ("Couldn't read bitmap colors", fp); skip_bytes (fp, 6);
/* @@ -108,11 +120,8 @@ int main (int argc, char *argv[]) DEFAULT_CMAP_SIZE);
/* allocate memory */ - if ((b->data = (uint8_t *)malloc(b->width * b->height)) == NULL) { - fclose (fp); - printf ("Error allocating memory for file %s.\n", argv[1]); - exit (EXIT_FAILURE); - } + if ((b->data = (uint8_t *)malloc(b->width * b->height)) == NULL) + error ("Error allocating memory for file", fp);
/* read and print the palette information */ printf ("unsigned short bmp_logo_palette[] = {\n");
Dear Peter Tyser,
In message 1240606796-32127-1-git-send-email-ptyser@xes-inc.com you wrote:
QWRkIGJhc2ljIGVycm9yIGhhbmRsaW5nIHRvIGZyZWFkKCkgZnVuY3Rpb24gY2FsbHMuICBUaGlz IHByZXZlbnRzCmNvbXBpbGlsYXRpb24gd2FybmluZ3Mgc3VjaCBhczoKCmJtcF9sb2dvLmM6IElu IGZ1bmN0aW9uIOKAmG1haW7igJk6CmJtcF9sb2dvLmM6NzE6IHdhcm5pbmc6IGlnbm9yaW5nIHJl dHVybiB2YWx1ZSBvZiDigJhmcmVhZOKAmSwgZGVjbGFyZWQgd2l0aAphdHRyaWJ1dGUgd2Fybl91 bnVzZWRfcmVzdWx0Ci4uLgoKU2lnbmVkLW9mZi1ieTogUGV0ZXIgVHlzZXIgPHB0eXNlckB4ZXMt aW5jLmNvbT4KLS0tCiB0b29scy9ibXBfbG9nby5jIHwgICAzNSArKysrKysrKysrKysrKysrKysr
...
Please do not post base64 encoded messages. Next time I will ignore such patches.
Add basic error handling to fread() function calls. This prevents compililation warnings such as:
bmp_logo.c: In function `main': bmp_logo.c:71: warning: ignoring return value of `fread', declared with attribute warn_unused_result ...
Signed-off-by: Peter Tyser ptyser@xes-inc.com
tools/bmp_logo.c | 35 ++++++++++++++++++++++------------- 1 files changed, 22 insertions(+), 13 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
On Monday 27 April 2009 19:18:21 Wolfgang Denk wrote:
In message Peter Tyser wrote:
<base64 stuff>
...
Please do not post base64 encoded messages. Next time I will ignore such patches.
it's due to unicode yet again:
bmp_logo.c: In function `main':
those ticks are probably the left & right unicode ticks that pretty much all GNU tools use. it's pretty hard for people to catch these things in the normal flow of git usage considering using a unicode locale setting and a GNU system is by and far the norm. -mike
On Mon, 2009-04-27 at 19:41 -0400, Mike Frysinger wrote:
On Monday 27 April 2009 19:18:21 Wolfgang Denk wrote:
In message Peter Tyser wrote:
<base64 stuff>
...
Please do not post base64 encoded messages. Next time I will ignore such patches.
it's due to unicode yet again:
bmp_logo.c: In function `main':
those ticks are probably the left & right unicode ticks that pretty much all GNU tools use. it's pretty hard for people to catch these things in the normal flow of git usage considering using a unicode locale setting and a GNU system is by and far the norm.
Ahhhh, thanks for the enlightenment - that makes sense. I use urxvt and pasted the output of a gcc warning in the commit message.
The copies cc-ed to myself come through just fine as utf-8 fwiw. Does that imply the denx.de servers convert unicode messages to base64?
In general, what's the proper workaround so things like this don't happen?
Peter
On Monday 27 April 2009 19:53:15 Peter Tyser wrote:
On Mon, 2009-04-27 at 19:41 -0400, Mike Frysinger wrote:
On Monday 27 April 2009 19:18:21 Wolfgang Denk wrote:
In message Peter Tyser wrote:
<base64 stuff>
...
Please do not post base64 encoded messages. Next time I will ignore such patches.
it's due to unicode yet again:
bmp_logo.c: In function `main':
those ticks are probably the left & right unicode ticks that pretty much all GNU tools use. it's pretty hard for people to catch these things in the normal flow of git usage considering using a unicode locale setting and a GNU system is by and far the norm.
Ahhhh, thanks for the enlightenment - that makes sense. I use urxvt and pasted the output of a gcc warning in the commit message.
which is reasonable and common behavior imo
The copies cc-ed to myself come through just fine as utf-8 fwiw. Does that imply the denx.de servers convert unicode messages to base64?
`git format-patch` did the right thing and converted the e-mail body to base64. if you do the format-patch again and edit the resulting file, you'll see it.
In general, what's the proper workaround so things like this don't happen?
there isnt a good one which is why i keep whining at Wolfgang to let it through. you can either not use a unicode environment at all (which sucks), or just remember this kind of thing and always check the output of git's format-patch before sending it. then when you notice, review the files to figure out where the unicode is coming from -- most of the time it's the commit message, but sometimes it comes from comments in the source code. so you have to keep your eyes open for umlauts and such (ëïöü).
i havent checked, but using extended codepages will probably also result in base64 encoding ... -mike
Dear Peter,
In message 1240876395.11057.126.camel@localhost.localdomain you wrote:
The copies cc-ed to myself come through just fine as utf-8 fwiw. Does that imply the denx.de servers convert unicode messages to base64?
This is in the headers of your message:
Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64
I don't think anything converted anything. It arrived as you sent it.
You just don't see it.
The problem for me is that I cannot use standard tools (like grep) on such messages.
Best regards,
Wolfgang Denk
Hi Wolfgang,
The copies cc-ed to myself come through just fine as utf-8 fwiw. Does that imply the denx.de servers convert unicode messages to base64?
This is in the headers of your message:
Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64
I don't think anything converted anything. It arrived as you sent it.
You just don't see it.
The problem for me is that I cannot use standard tools (like grep) on such messages.
Isn't it possible that you un-base64 such mails locally in your mail system? In the long run I'd really like to be able to handle Unicode in U-Boot (sources) and thus also on the mailing list.
It is the 2000s after all with people from all over the world contributing to U-Boot and we're limiting ourselves to the english typographic letters :(
Cheers Detlev
On Tuesday 28 April 2009 05:11:01 Detlev Zundel wrote:
Hi Wolfgang,
The copies cc-ed to myself come through just fine as utf-8 fwiw. Does that imply the denx.de servers convert unicode messages to base64?
This is in the headers of your message:
Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64
I don't think anything converted anything. It arrived as you sent it.
You just don't see it.
The problem for me is that I cannot use standard tools (like grep) on such messages.
Isn't it possible that you un-base64 such mails locally in your mail system? In the long run I'd really like to be able to handle Unicode in U-Boot (sources) and thus also on the mailing list.
It is the 2000s after all with people from all over the world contributing to U-Boot and we're limiting ourselves to the english typographic letters :(
i dont think we want localized comments/output without an english equivalent. i.e. if someone proposed an optional gettext() kind of thing so the output of u-boot were localized, that may make sense.
mixing language comments makes it kind of hard for people to coordinate/review things as then they'd be required to know multiple languages. atm, english is the only thing required (well, and coding ability of course). -mike
Hi Mike,
On Tuesday 28 April 2009 05:11:01 Detlev Zundel wrote:
Hi Wolfgang,
The copies cc-ed to myself come through just fine as utf-8 fwiw. Does that imply the denx.de servers convert unicode messages to base64?
This is in the headers of your message:
Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64
I don't think anything converted anything. It arrived as you sent it.
You just don't see it.
The problem for me is that I cannot use standard tools (like grep) on such messages.
Isn't it possible that you un-base64 such mails locally in your mail system? In the long run I'd really like to be able to handle Unicode in U-Boot (sources) and thus also on the mailing list.
It is the 2000s after all with people from all over the world contributing to U-Boot and we're limiting ourselves to the english typographic letters :(
i dont think we want localized comments/output without an english equivalent. i.e. if someone proposed an optional gettext() kind of thing so the output of u-boot were localized, that may make sense.
Note that I explicitely hinted at the source code.
mixing language comments makes it kind of hard for people to coordinate/review things as then they'd be required to know multiple languages. atm, english is the only thing required (well, and coding ability of course).
I wasn't even thinking about language comments but simply names especially in git-commit messages.
Obviously I'm lucky that I don't have an umlaut in my name, but if I had, what would I do? Resort to latin-1? What about French, Russian, etc. developers who want to see their "real" name in the logs?
Cheers Detlev
On Tuesday 28 April 2009 13:06:00 Detlev Zundel wrote:
On Tuesday 28 April 2009 05:11:01 Detlev Zundel wrote:
The copies cc-ed to myself come through just fine as utf-8 fwiw. Does that imply the denx.de servers convert unicode messages to base64?
This is in the headers of your message:
Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64
I don't think anything converted anything. It arrived as you sent it.
You just don't see it.
The problem for me is that I cannot use standard tools (like grep) on such messages.
Isn't it possible that you un-base64 such mails locally in your mail system? In the long run I'd really like to be able to handle Unicode in U-Boot (sources) and thus also on the mailing list.
It is the 2000s after all with people from all over the world contributing to U-Boot and we're limiting ourselves to the english typographic letters :(
i dont think we want localized comments/output without an english equivalent. i.e. if someone proposed an optional gettext() kind of thing so the output of u-boot were localized, that may make sense.
Note that I explicitely hinted at the source code.
mixing language comments makes it kind of hard for people to coordinate/review things as then they'd be required to know multiple languages. atm, english is the only thing required (well, and coding ability of course).
I wasn't even thinking about language comments but simply names especially in git-commit messages.
i have no problem with localized names. i do have a problem with localized comments and source code.
Obviously I'm lucky that I don't have an umlaut in my name, but if I had, what would I do?
currently, like every other person with an umlaut, you use an "e". ö -> oe.
Resort to latin-1?
presumably you mean ISO 8859-1, and in that case, that character set is the same as in unicode (it was designed that way).
What about French, Russian, etc. developers who want to see their "real" name in the logs?
get a new name ! -mike
Hi Mike,
I wasn't even thinking about language comments but simply names especially in git-commit messages.
i have no problem with localized names. i do have a problem with localized comments and source code.
Ok, so we're more or less in accord - remembering that names also show up in git-logs and thus may force an encoding on the patches.
Obviously I'm lucky that I don't have an umlaut in my name, but if I had, what would I do?
currently, like every other person with an umlaut, you use an "e". ö -> oe.
This was a solution of the 1900s, but I was under the impression, that modern systems can cope with non-ascii characters, no?
Resort to latin-1?
I was unclear - what I meant was to use a "iso 8859-1" encoding without explicitely stating it, i.e. that the > 0x7f byte is from 8859-1?
presumably you mean ISO 8859-1, and in that case, that character set is the same as in unicode (it was designed that way).
Well it may be at the same unicode position, but the encoding in byte strings is still different of course. The 8859-1 umlaut "ä" (= 0xe4 in 8859-1) is encoded as 0xce 0xa4 in utf-8 encoding which seems slightly different.
What about French, Russian, etc. developers who want to see their "real" name in the logs?
get a new name !
Ah, the solution was so plain obvious all along :)
Cheers Detlev
On Thursday 30 April 2009 10:00:41 Detlev Zundel wrote:
I wasn't even thinking about language comments but simply names especially in git-commit messages.
i have no problem with localized names. i do have a problem with localized comments and source code.
Ok, so we're more or less in accord - remembering that names also show up in git-logs and thus may force an encoding on the patches.
the encoding is going to be forced regardless of location of the unicode chars. and in the case of mailman, it's going to get base64 encoded.
Obviously I'm lucky that I don't have an umlaut in my name, but if I had, what would I do?
currently, like every other person with an umlaut, you use an "e". ö -> oe.
This was a solution of the 1900s, but I was under the impression, that modern systems can cope with non-ascii characters, no?
if it means the patch gets base64 encoded, then Wolfgang isnt going to accept it. so that method is still relevant.
if mailman were fixed, then i imagine Wolfgang wouldnt have a problem anymore (assuming he even noticed) ...
Resort to latin-1?
I was unclear - what I meant was to use a "iso 8859-1" encoding without explicitely stating it, i.e. that the > 0x7f byte is from 8859-1?
presumably you mean ISO 8859-1, and in that case, that character set is the same as in unicode (it was designed that way).
Well it may be at the same unicode position, but the encoding in byte strings is still different of course. The 8859-1 umlaut "ä" (= 0xe4 in 8859-1) is encoded as 0xce 0xa4 in utf-8 encoding which seems slightly different.
i meant it's forward compatible. any character encoded in ISO 8859-1 will work properly with unicode by design. i didnt mean that unicode encodings will be single byte and thus the same as ISO 8859-1.
this charset btw covers most European countries. -mike
Hi Wolfgang,
The copies cc-ed to myself come through just fine as utf-8 fwiw. Does that imply the denx.de servers convert unicode messages to base64?
This is in the headers of your message:
Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64
I don't think anything converted anything. It arrived as you sent it.
'git send-email' cc-ed me a copy of the patch as well as sent it to the mailing list. The copy cc-ed directly to me had the following headers:
Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit
However, the copy received from denx.de had the headers:
Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by xes-inc.com id n3OL05sk002907
Based on the "Autoconverted" line my guess is the email from denx.de was in base64 and our email server automatically converted it to 8bit encoding.
You just don't see it.
I (think I) see base64 coming from denx.de, but not from our mail server.
The headers imply that a server outside xes-inc.com converted the 8bit/utf-8 message into base64/utf-8. Perhaps denx.de doesn't support the 8BITMIME SMTP extension? Or something along those lines? Or am I missing something?
The problem for me is that I cannot use standard tools (like grep) on such messages.
If the messages were encoded in 8bit mode instead of base64 they should still be grep-able (other than the unicode chars).
Best, Peter
On Tuesday 28 April 2009 11:06:06 Peter Tyser wrote:
The copies cc-ed to myself come through just fine as utf-8 fwiw. Does that imply the denx.de servers convert unicode messages to base64?
This is in the headers of your message:
Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64
I don't think anything converted anything. It arrived as you sent it.
'git send-email' cc-ed me a copy of the patch as well as sent it to the mailing list. The copy cc-ed directly to me had the following headers:
Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit
However, the copy received from denx.de had the headers:
Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by xes-inc.com id n3OL05sk002907
Based on the "Autoconverted" line my guess is the email from denx.de was in base64 and our email server automatically converted it to 8bit encoding.
hmm, maybe newer versions of git dont convert to base64 ... i tested 1.6.2.3 and it doesnt mung the subject or the content anymore. the subject however does get encoded with =?utf-8?, but there isnt anything we can do about that as that is part of the e-mail spec.
You just don't see it.
I (think I) see base64 coming from denx.de, but not from our mail server.
The headers imply that a server outside xes-inc.com converted the 8bit/utf-8 message into base64/utf-8. Perhaps denx.de doesn't support the 8BITMIME SMTP extension? Or something along those lines? Or am I missing something?
the header says "by xes-inc.com" which kind of implies it was your e-mail server doing it ...
you could try sending me the aforementioned patch directly and see if it happens when i get it ... -mike
On Tue, 2009-04-28 at 11:49 -0400, Mike Frysinger wrote:
On Tuesday 28 April 2009 11:06:06 Peter Tyser wrote:
The copies cc-ed to myself come through just fine as utf-8 fwiw. Does that imply the denx.de servers convert unicode messages to base64?
This is in the headers of your message:
Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64
I don't think anything converted anything. It arrived as you sent it.
'git send-email' cc-ed me a copy of the patch as well as sent it to the mailing list. The copy cc-ed directly to me had the following headers:
Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit
However, the copy received from denx.de had the headers:
Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by xes-inc.com id n3OL05sk002907
Based on the "Autoconverted" line my guess is the email from denx.de was in base64 and our email server automatically converted it to 8bit encoding.
hmm, maybe newer versions of git dont convert to base64 ... i tested 1.6.2.3 and it doesnt mung the subject or the content anymore. the subject however does get encoded with =?utf-8?, but there isnt anything we can do about that as that is part of the e-mail spec.
Yeah, in the original patch I see (git 1.6.2.1): ... Subject: [PATCH] bmp_logo: Check return value of fread() MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit
Add basic error handling to fread() function calls. This prevents ...
You just don't see it.
I (think I) see base64 coming from denx.de, but not from our mail server.
The headers imply that a server outside xes-inc.com converted the 8bit/utf-8 message into base64/utf-8. Perhaps denx.de doesn't support the 8BITMIME SMTP extension? Or something along those lines? Or am I missing something?
the header says "by xes-inc.com" which kind of implies it was your e-mail server doing it ...
The header in the email from denx.de says "X-MIME-Autoconverted: from base64 to 8bit by xes-inc.com" which implies to me the inbound email from denx.de was base64. In contrast the email from xes-inc.com didn't have the "base64 to 8bit" message which implies xes-inc.com sent it out in 8bit/utf-8 as desired.
you could try sending me the aforementioned patch directly and see if it happens when i get it ...
Will do.
Thanks, Peter
On Tuesday 28 April 2009 11:57:37 Peter Tyser wrote:
On Tue, 2009-04-28 at 11:49 -0400, Mike Frysinger wrote:
On Tuesday 28 April 2009 11:06:06 Peter Tyser wrote:
You just don't see it.
I (think I) see base64 coming from denx.de, but not from our mail server.
The headers imply that a server outside xes-inc.com converted the 8bit/utf-8 message into base64/utf-8. Perhaps denx.de doesn't support the 8BITMIME SMTP extension? Or something along those lines? Or am I missing something?
the header says "by xes-inc.com" which kind of implies it was your e-mail server doing it ...
The header in the email from denx.de says "X-MIME-Autoconverted: from base64 to 8bit by xes-inc.com" which implies to me the inbound email from denx.de was base64. In contrast the email from xes-inc.com didn't have the "base64 to 8bit" message which implies xes-inc.com sent it out in 8bit/utf-8 as desired.
you could try sending me the aforementioned patch directly and see if it happens when i get it ...
Will do.
the two e-mails you sent me directly were not base64 encoded, but the ones on the list clearly are base64 encoded ... -mike
On Tuesday 28 April 2009 11:06:06 Peter Tyser wrote:
I (think I) see base64 coming from denx.de, but not from our mail server.
blah, this seems to be all mailman's fault. apparently, it can only be changed by disabling the msg_footer/msg_header options. http://mail.python.org/pipermail/mailman-users/2008-September/063295.html
The headers imply that a server outside xes-inc.com converted the 8bit/utf-8 message into base64/utf-8. Perhaps denx.de doesn't support the 8BITMIME SMTP extension? Or something along those lines? Or am I missing something?
i think you're interpreting the header the wrong way. it says that denx.de sent out a base64 message but your mail server converted it back to 8bit for you. -mike
On Tue, 2009-04-28 at 13:22 -0400, Mike Frysinger wrote:
On Tuesday 28 April 2009 11:06:06 Peter Tyser wrote:
I (think I) see base64 coming from denx.de, but not from our mail server.
blah, this seems to be all mailman's fault. apparently, it can only be changed by disabling the msg_footer/msg_header options. http://mail.python.org/pipermail/mailman-users/2008-September/063295.html
That's a real nice workaround:)
The headers imply that a server outside xes-inc.com converted the 8bit/utf-8 message into base64/utf-8. Perhaps denx.de doesn't support the 8BITMIME SMTP extension? Or something along those lines? Or am I missing something?
i think you're interpreting the header the wrong way. it says that denx.de sent out a base64 message but your mail server converted it back to 8bit for you.
I think we're on the same page. I've been trying to say: 1. xes sends a 8bit email to denx.de
2. denx.de converts the 8bit email to base64 (likely mailman based on the link above)
3. denx.de sends a base64 email back to me at xes (and everyone else on the list)
4.a. our xes server automatically converts the base64 email to 8bit
4.b. denx.de email server doesn't convert base64 email to 8bit email and then Wolfgang complains, just like I would:)
Peter
participants (4)
-
Detlev Zundel -
Mike Frysinger -
Peter Tyser -
Wolfgang Denk