[U-Boot] [PATCH] bmp_logo: Check return value of fread()

[U-Boot] [PATCH] bmp_logo: Check return value of fread()

[Peter Tyser]

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");
-- 
1.6.2.1

[U-Boot] [PATCH] bmp_logo: Check return value of fread()

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If I have seen further it is by standing on the shoulders of  giants.
              - Isaac Newton, Letter to Robert Hooke, 5 February 1676

[U-Boot] [PATCH] bmp_logo: Check return value of fread()

[Mike Frysinger]

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

[U-Boot] [PATCH] bmp_logo: Check return value of fread()

[Peter Tyser]

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

[U-Boot] [PATCH] bmp_logo: Check return value of fread()

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090427/90e6cfe1/attachment.pgp 

[U-Boot] [PATCH] bmp_logo: Check return value of fread()

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Each honest calling, each walk of life, has its own  elite,  its  own
aristocracy based on excellence of performance. - James Bryant Conant

[U-Boot] [PATCH] bmp_logo: Check return value of fread()

[Detlev Zundel]

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

-- 
Man is a fool, and woman, for tolerating him, is a damned fool
                       -- Mark Twain
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] [PATCH] bmp_logo: Check return value of fread()

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090428/cdbc0797/attachment.pgp 

[U-Boot] [PATCH] bmp_logo: Check return value of fread()

[Peter Tyser]

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

[U-Boot] [PATCH] bmp_logo: Check return value of fread()

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090428/03ff1d07/attachment.pgp 

[U-Boot] [PATCH] bmp_logo: Check return value of fread()

[Peter Tyser]

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

[U-Boot] [PATCH] bmp_logo: Check return value of fread()

[Mike Frysinger]

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

[U-Boot] [PATCH] bmp_logo: Check return value of fread()

[Detlev Zundel]

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

-- 
Of course my password is the same as my pet's name
My macaw's name was Q47pY!3 and I change it every 90 days
                        -- Trevor Linton
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] [PATCH] bmp_logo: Check return value of fread()

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090428/214c5af3/attachment-0001.pgp 

[U-Boot] [PATCH] bmp_logo: Check return value of fread()

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090428/d9f5f11b/attachment.pgp 

[U-Boot] [PATCH] bmp_logo: Check return value of fread()

[Peter Tyser]

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

[U-Boot] [PATCH] bmp_logo: Check return value of fread()

[Detlev Zundel]

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

-- 
C hasn't changed much since the 1970s. And let's face it it's ugly.
Can't we do better? C++? (Sorry, never mind.)
                                    -- Rob Pike
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] [PATCH] bmp_logo: Check return value of fread()

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090430/3ba38403/attachment.pgp