[PATCH -mm] sb16: Shut up uninitialized var build warning

[PATCH -mm] sb16: Shut up uninitialized var build warning

[Satyam Sharma]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1127 bytes --]


sound/isa/sb16/sb16.c: In function ‘snd_sb16_isa_probe’:
sound/isa/sb16/sb16.c:559: warning: ‘err’ may be used uninitialized in this function

is a bogus warning, so let's shut it up.

Signed-off-by: Satyam Sharma <satyam@infradead.org>

---

 sound/isa/sb/sb16.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- linux-2.6.23-rc4-mm1/sound/isa/sb/sb16.c~fix	2007-09-02 21:41:51.000000000 +0530
+++ linux-2.6.23-rc4-mm1/sound/isa/sb/sb16.c	2007-09-02 21:42:56.000000000 +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);

[PATCH -mm] es18xx: Shut up uninitialized var build warning

[Satyam Sharma]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1135 bytes --]


sound/isa/es18xx.c: In function ‘snd_es18xx_isa_probe’:
sound/isa/es18xx.c:2251: warning: ‘err’ may be used uninitialized in this function

gcc is a sad, sad compiler. This warning is bogus so let's shut it up.

Signed-off-by: Satyam Sharma <satyam@infradead.org>

---

 sound/isa/es18xx.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- linux-2.6.23-rc4-mm1/sound/isa/es18xx.c~fix	2007-09-02 21:16:54.000000000 +0530
+++ linux-2.6.23-rc4-mm1/sound/isa/es18xx.c	2007-09-02 21:30:13.000000000 +0530
@@ -2248,7 +2248,6 @@ static int __devinit snd_es18xx_isa_prob
 
 static int __devinit snd_es18xx_isa_probe(struct device *pdev, unsigned int dev)
 {
-	int err;
 	static int possible_irqs[] = {5, 9, 10, 7, 11, 12, -1};
 	static int possible_dmas[] = {1, 0, 3, 5, -1};
 
@@ -2276,6 +2275,8 @@ static int __devinit snd_es18xx_isa_prob
 	} else {
 		static unsigned long 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_es18xx_isa_probe1(dev, pdev);

Re: [PATCH -mm] sb16: Shut up uninitialized var build warning

[Rene Herman]

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~fix	2007-09-02 21:41:51.000000000 +0530
> +++ linux-2.6.23-rc4-mm1/sound/isa/sb/sb16.c	2007-09-02 21:42:56.000000000 +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.

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH -mm] es18xx: Shut up uninitialized var build warning

[Rene Herman]

On 09/02/2007 10:21 PM, Satyam Sharma wrote:

> sound/isa/es18xx.c: In function ‘snd_es18xx_isa_probe’:
> sound/isa/es18xx.c:2251: warning: ‘err’ may be used uninitialized in this function
> 
> gcc is a sad, sad compiler. This warning is bogus so let's shut it up.

Same situation, same comment (and same charset :-( ) as the sb16 one.

Rene.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH -mm] sb16: Shut up uninitialized var build warning

[Satyam Sharma]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1132 bytes --]



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.

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH -mm] sb16: Shut up uninitialized var build warning

[Denys Vlasenko]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH -mm] sb16: Shut up uninitialized var build warning

[Rene Herman]

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.