Re: [PATCH -mm] sb16: Shut up uninitialized var build warning
On 09/20/2007 07:52 PM, Denys Vlasenko wrote: On Sunday 02 September 2007 23:06, Rene Herman wrote: Blah. Your message has: Content-Type: TEXT/PLAIN; charset=iso-2022-jp This apparently is caused by a combination of GCC using groovy UTF tickmarks in its error messages when in a UTF locale and alpine believing it to be a great idea to automatically try for the "simplest" character set it can encode the content in. No idea why that means that iso-2022-jp is picked, but it is. While I could actually read the message this time you should see what iso-2022-jp does to my font. It's scary. Best solution as far as I'm concerned is slap a few GCC developers (not that it wil help, but it'll certainly feel good) and then teach alpine to go for UTF-8 directly if US-ASCII won't do. rotfl. Kindly give me permission to convert your email into gcc bugreport and/or to forward it to gcc mailing list. Blessings be upon thou, oh courageous one... Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] sb16: Shut up uninitialized var build warning
On 09/20/2007 07:52 PM, Denys Vlasenko wrote: On Sunday 02 September 2007 23:06, Rene Herman wrote: Blah. Your message has: Content-Type: TEXT/PLAIN; charset=iso-2022-jp This apparently is caused by a combination of GCC using groovy UTF tickmarks in its error messages when in a UTF locale and alpine believing it to be a great idea to automatically try for the simplest character set it can encode the content in. No idea why that means that iso-2022-jp is picked, but it is. While I could actually read the message this time you should see what iso-2022-jp does to my font. It's scary. Best solution as far as I'm concerned is slap a few GCC developers (not that it wil help, but it'll certainly feel good) and then teach alpine to go for UTF-8 directly if US-ASCII won't do. rotfl. Kindly give me permission to convert your email into gcc bugreport and/or to forward it to gcc mailing list. Blessings be upon thou, oh courageous one... Rene. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] sb16: Shut up uninitialized var build warning
On Sunday 02 September 2007 23:06, Rene Herman wrote: > On 09/02/2007 10:15 PM, Satyam Sharma wrote: > > > sound/isa/sb16/sb16.c: In function ‘snd_sb16_isa_probe’: > > Blah. Your message has: > > Content-Type: TEXT/PLAIN; charset=iso-2022-jp > > This apparently is caused by a combination of GCC using groovy UTF tickmarks > in its error messages when in a UTF locale and alpine believing it to be a > great idea to automatically try for the "simplest" character set it can > encode the content in. No idea why that means that iso-2022-jp is picked, > but it is. > > While I could actually read the message this time you should see what > iso-2022-jp does to my font. It's scary. Best solution as far as I'm > concerned is slap a few GCC developers (not that it wil help, but it'll > certainly feel good) and then teach alpine to go for UTF-8 directly if > US-ASCII won't do. rotfl. Kindly give me permission to convert your email into gcc bugreport and/or to forward it to gcc mailing list. -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] sb16: Shut up uninitialized var build warning
On Sunday 02 September 2007 23:06, Rene Herman wrote: On 09/02/2007 10:15 PM, Satyam Sharma wrote: sound/isa/sb16/sb16.c: In function ‘snd_sb16_isa_probe’: Blah. Your message has: Content-Type: TEXT/PLAIN; charset=iso-2022-jp This apparently is caused by a combination of GCC using groovy UTF tickmarks in its error messages when in a UTF locale and alpine believing it to be a great idea to automatically try for the simplest character set it can encode the content in. No idea why that means that iso-2022-jp is picked, but it is. While I could actually read the message this time you should see what iso-2022-jp does to my font. It's scary. Best solution as far as I'm concerned is slap a few GCC developers (not that it wil help, but it'll certainly feel good) and then teach alpine to go for UTF-8 directly if US-ASCII won't do. rotfl. Kindly give me permission to convert your email into gcc bugreport and/or to forward it to gcc mailing list. -- vda - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] sb16: Shut up uninitialized var build warning
On Mon, 3 Sep 2007, Rene Herman wrote: > > On 09/02/2007 10:15 PM, Satyam Sharma wrote: > > > sound/isa/sb16/sb16.c: In function ‘snd_sb16_isa_probe’: > > Blah. Your message has: > > Content-Type: TEXT/PLAIN; charset=iso-2022-jp > > This apparently is caused by a combination of GCC using groovy UTF tickmarks > in its error messages when in a UTF locale and alpine believing it to be a > great idea to automatically try for the "simplest" character set it can encode > the content in. No idea why that means that iso-2022-jp is picked, but it is. Yeah, precisely. > As to the content of this patch -- I'd almost say it's better to live with the > warning than with that unitialized_var() thing. That ARRAY_SIZE is very much a > compile time constant, so exactly how dumb must GCC get before we get to say > to here and no further? Pretty dumb indeed -- in fact that's the case with 4 patches in this series. Like Jeff said, that (gcc's) behaviour has likely even improved w.r.t. later versions, so I guess it's fine if these 4 patches are not applied -- I'll leave it upto the maintainers.
Re: [PATCH -mm] sb16: Shut up uninitialized var build warning
On 09/02/2007 10:15 PM, Satyam Sharma wrote:
sound/isa/sb16/sb16.c: In function ‘snd_sb16_isa_probe’:
Blah. Your message has:
Content-Type: TEXT/PLAIN; charset=iso-2022-jp
This apparently is caused by a combination of GCC using groovy UTF tickmarks
in its error messages when in a UTF locale and alpine believing it to be a
great idea to automatically try for the "simplest" character set it can
encode the content in. No idea why that means that iso-2022-jp is picked,
but it is.
While I could actually read the message this time you should see what
iso-2022-jp does to my font. It's scary. Best solution as far as I'm
concerned is slap a few GCC developers (not that it wil help, but it'll
certainly feel good) and then teach alpine to go for UTF-8 directly if
US-ASCII won't do.
As to the content of this patch -- I'd almost say it's better to live with
the warning than with that unitialized_var() thing. That ARRAY_SIZE is very
much a compile time constant, so exactly how dumb must GCC get before we get
to say to here and no further?
--- linux-2.6.23-rc4-mm1/sound/isa/sb/sb16.c~fix2007-09-02
21:41:51.0 +0530
+++ linux-2.6.23-rc4-mm1/sound/isa/sb/sb16.c2007-09-02 21:42:56.0
+0530
@@ -556,7 +556,6 @@ static int __devinit snd_sb16_isa_match(
static int __devinit snd_sb16_isa_probe(struct device *pdev, unsigned int dev)
{
- int err;
static int possible_irqs[] = {5, 9, 10, 7, -1};
static int possible_dmas8[] = {1, 3, 0, -1};
static int possible_dmas16[] = {5, 6, 7, -1};
@@ -585,6 +584,8 @@ static int __devinit snd_sb16_isa_probe(
else {
static int possible_ports[] = {0x220, 0x240, 0x260, 0x280};
int i;
+ int uninitialized_var(err);
+
for (i = 0; i < ARRAY_SIZE(possible_ports); i++) {
port[dev] = possible_ports[i];
err = snd_sb16_isa_probe1(dev, pdev);
Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] sb16: Shut up uninitialized var build warning
On 09/02/2007 10:15 PM, Satyam Sharma wrote:
sound/isa/sb16/sb16.c: In function ‘snd_sb16_isa_probe’:
Blah. Your message has:
Content-Type: TEXT/PLAIN; charset=iso-2022-jp
This apparently is caused by a combination of GCC using groovy UTF tickmarks
in its error messages when in a UTF locale and alpine believing it to be a
great idea to automatically try for the simplest character set it can
encode the content in. No idea why that means that iso-2022-jp is picked,
but it is.
While I could actually read the message this time you should see what
iso-2022-jp does to my font. It's scary. Best solution as far as I'm
concerned is slap a few GCC developers (not that it wil help, but it'll
certainly feel good) and then teach alpine to go for UTF-8 directly if
US-ASCII won't do.
As to the content of this patch -- I'd almost say it's better to live with
the warning than with that unitialized_var() thing. That ARRAY_SIZE is very
much a compile time constant, so exactly how dumb must GCC get before we get
to say to here and no further?
--- linux-2.6.23-rc4-mm1/sound/isa/sb/sb16.c~fix2007-09-02
21:41:51.0 +0530
+++ linux-2.6.23-rc4-mm1/sound/isa/sb/sb16.c2007-09-02 21:42:56.0
+0530
@@ -556,7 +556,6 @@ static int __devinit snd_sb16_isa_match(
static int __devinit snd_sb16_isa_probe(struct device *pdev, unsigned int dev)
{
- int err;
static int possible_irqs[] = {5, 9, 10, 7, -1};
static int possible_dmas8[] = {1, 3, 0, -1};
static int possible_dmas16[] = {5, 6, 7, -1};
@@ -585,6 +584,8 @@ static int __devinit snd_sb16_isa_probe(
else {
static int possible_ports[] = {0x220, 0x240, 0x260, 0x280};
int i;
+ int uninitialized_var(err);
+
for (i = 0; i ARRAY_SIZE(possible_ports); i++) {
port[dev] = possible_ports[i];
err = snd_sb16_isa_probe1(dev, pdev);
Rene.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] sb16: Shut up uninitialized var build warning
On Mon, 3 Sep 2007, Rene Herman wrote: On 09/02/2007 10:15 PM, Satyam Sharma wrote: sound/isa/sb16/sb16.c: In function ‘snd_sb16_isa_probe’: Blah. Your message has: Content-Type: TEXT/PLAIN; charset=iso-2022-jp This apparently is caused by a combination of GCC using groovy UTF tickmarks in its error messages when in a UTF locale and alpine believing it to be a great idea to automatically try for the simplest character set it can encode the content in. No idea why that means that iso-2022-jp is picked, but it is. Yeah, precisely. As to the content of this patch -- I'd almost say it's better to live with the warning than with that unitialized_var() thing. That ARRAY_SIZE is very much a compile time constant, so exactly how dumb must GCC get before we get to say to here and no further? Pretty dumb indeed -- in fact that's the case with 4 patches in this series. Like Jeff said, that (gcc's) behaviour has likely even improved w.r.t. later versions, so I guess it's fine if these 4 patches are not applied -- I'll leave it upto the maintainers.
