Kill a warning building mg with clang
Hi tech@ --
Clang points this out when building mg:
clang -O2 -pipe -Wall -DFKEYS -DREGEX -DXKEYS -c /home/brian/mg/buffer.c
/home/brian/mg/buffer.c:461:11: warning: comparison of array
'bp->b_fname' not equal to a null pointer is always true
[-Wtautological-pointer-compare]
if (bp->b_fname != NULL && *(bp->b_fname) != '\0' &&
^~~
1 warning generated.
Diff below to kill the warning.
OK?
~Brian
Index: buffer.c
===
RCS file: /cvs/src/usr.bin/mg/buffer.c,v
retrieving revision 1.93
diff -u -p -r1.93 buffer.c
--- buffer.c20 Mar 2014 07:47:29 - 1.93
+++ buffer.c12 Jun 2014 03:33:34 -
@@ -458,7 +458,7 @@ anycb(int f)
char pbuf[NFILEN + 11];
for (bp = bheadp; bp != NULL; bp = bp->b_bufp) {
- if (bp->b_fname != NULL && *(bp->b_fname) != '\0' &&
+ if (*(bp->b_fname) != '\0' &&
(bp->b_flag & BFCHG) != 0) {
ret = snprintf(pbuf, sizeof(pbuf), "Save file %s",
bp->b_fname);
Re: acpiec(4): clear events based on vendor
On 2014/06/12 01:09, Paul Irofti wrote: > On Wed, Jun 11, 2014 at 02:49:41PM -0700, Mike Larkin wrote: > > On Thu, Jun 12, 2014 at 12:45:23AM +0300, Paul Irofti wrote: > > > On Wed, Jun 11, 2014 at 09:42:56PM +0200, Mark Kettenis wrote: > > > > > Date: Wed, 11 Jun 2014 08:40:51 +0200 > > > > > From: Remi Locherer > > > > > > > > > > On Wed, Jun 11, 2014 at 09:11:54AM +0300, Paul Irofti wrote: > > > > > > On Tue, Jun 10, 2014 at 11:50:02PM +0200, Remi Locherer wrote: > > > > > > > On Tue, Jun 10, 2014 at 06:25:33PM +0300, Paul Irofti wrote: > > > > > > > > After discussions with Theo we decided to walk the table where > > > > > > > > needed > > > > > > > > instead of using the soft state variables. > > > > > > > > > > > > > > > > Also adding all the Samsung models to the quirks table (as per > > > > > > > > the > > > > > > > > Linux EC quirks table). > > > > > > > > > > > > > > > > > > > > > > I tried this diff with my Samsung notebook. With sysctl > > > > > > > hw.sensors or > > > > > > > apm the state of the power supply is displayed correctly. If I > > > > > > > change the > > > > > > > status (disconnect or connect again) this is then also showed > > > > > > > correctly. > > > > > > > > > > > > So this time it works... Did you apply the diff on top of a current > > > > > > sys? > > > > > > > > > > I did a cvs up on June 10 and applied this diff on top of that. > > > > > > > > > > > > > > > > > > But a current kernel (checkout from June 10) with this patch > > > > > > > applied does > > > > > > > not show the acpibat0 sensor values correctly. > > > > > > > > > > > > And this time it does not? > > > > > > > > > > With this diff hw.sensors.acpiac0.indicator0 works correctly but > > > > > hw.sensors.acpibat0.amphourX does not. With snapshot kernels from > > > > > June 6 > > > > > and June 10 it's the other way round. > > > > > > > > > > > > > > > > > I'm confused :-) > > > > > > > > > > I can imagin - the complexity of acpi combined with Samsung's > > > > > implementation > > > > > and my imprecise description ... ;-) > > > > > > > > Our acpi code does something wrong. This seems to be the root cause > > > > of the acpitz(4) problems that we're seeing on a wider variety of > > > > hardware. I really think we should try to fix that broader issue > > > > before trying to fix this more specific suspend/resume issue on > > > > Samsung hardware. > > > > > > Sure. This is not at all urgent. It can wait for someone to fix > > > acpitz(4) on those machines. > > > > /me ducks :) > > > > I don't think there's any need for ducking, last I remember you don't > own a Samsung machine. > Perhaps Mike is ducking in case any low-flying samsung machines head in his direction!
Re: acpiec(4): clear events based on vendor
On Wed, Jun 11, 2014 at 02:49:41PM -0700, Mike Larkin wrote: > On Thu, Jun 12, 2014 at 12:45:23AM +0300, Paul Irofti wrote: > > On Wed, Jun 11, 2014 at 09:42:56PM +0200, Mark Kettenis wrote: > > > > Date: Wed, 11 Jun 2014 08:40:51 +0200 > > > > From: Remi Locherer > > > > > > > > On Wed, Jun 11, 2014 at 09:11:54AM +0300, Paul Irofti wrote: > > > > > On Tue, Jun 10, 2014 at 11:50:02PM +0200, Remi Locherer wrote: > > > > > > On Tue, Jun 10, 2014 at 06:25:33PM +0300, Paul Irofti wrote: > > > > > > > After discussions with Theo we decided to walk the table where > > > > > > > needed > > > > > > > instead of using the soft state variables. > > > > > > > > > > > > > > Also adding all the Samsung models to the quirks table (as per the > > > > > > > Linux EC quirks table). > > > > > > > > > > > > > > > > > > > I tried this diff with my Samsung notebook. With sysctl hw.sensors > > > > > > or > > > > > > apm the state of the power supply is displayed correctly. If I > > > > > > change the > > > > > > status (disconnect or connect again) this is then also showed > > > > > > correctly. > > > > > > > > > > So this time it works... Did you apply the diff on top of a current > > > > > sys? > > > > > > > > I did a cvs up on June 10 and applied this diff on top of that. > > > > > > > > > > > > > > > But a current kernel (checkout from June 10) with this patch > > > > > > applied does > > > > > > not show the acpibat0 sensor values correctly. > > > > > > > > > > And this time it does not? > > > > > > > > With this diff hw.sensors.acpiac0.indicator0 works correctly but > > > > hw.sensors.acpibat0.amphourX does not. With snapshot kernels from June 6 > > > > and June 10 it's the other way round. > > > > > > > > > > > > > > I'm confused :-) > > > > > > > > I can imagin - the complexity of acpi combined with Samsung's > > > > implementation > > > > and my imprecise description ... ;-) > > > > > > Our acpi code does something wrong. This seems to be the root cause > > > of the acpitz(4) problems that we're seeing on a wider variety of > > > hardware. I really think we should try to fix that broader issue > > > before trying to fix this more specific suspend/resume issue on > > > Samsung hardware. > > > > Sure. This is not at all urgent. It can wait for someone to fix > > acpitz(4) on those machines. > > /me ducks :) > I don't think there's any need for ducking, last I remember you don't own a Samsung machine.
Re: acpiec(4): clear events based on vendor
On Thu, Jun 12, 2014 at 12:45:23AM +0300, Paul Irofti wrote: > On Wed, Jun 11, 2014 at 09:42:56PM +0200, Mark Kettenis wrote: > > > Date: Wed, 11 Jun 2014 08:40:51 +0200 > > > From: Remi Locherer > > > > > > On Wed, Jun 11, 2014 at 09:11:54AM +0300, Paul Irofti wrote: > > > > On Tue, Jun 10, 2014 at 11:50:02PM +0200, Remi Locherer wrote: > > > > > On Tue, Jun 10, 2014 at 06:25:33PM +0300, Paul Irofti wrote: > > > > > > After discussions with Theo we decided to walk the table where > > > > > > needed > > > > > > instead of using the soft state variables. > > > > > > > > > > > > Also adding all the Samsung models to the quirks table (as per the > > > > > > Linux EC quirks table). > > > > > > > > > > > > > > > > I tried this diff with my Samsung notebook. With sysctl hw.sensors or > > > > > apm the state of the power supply is displayed correctly. If I change > > > > > the > > > > > status (disconnect or connect again) this is then also showed > > > > > correctly. > > > > > > > > So this time it works... Did you apply the diff on top of a current sys? > > > > > > I did a cvs up on June 10 and applied this diff on top of that. > > > > > > > > > > > > But a current kernel (checkout from June 10) with this patch applied > > > > > does > > > > > not show the acpibat0 sensor values correctly. > > > > > > > > And this time it does not? > > > > > > With this diff hw.sensors.acpiac0.indicator0 works correctly but > > > hw.sensors.acpibat0.amphourX does not. With snapshot kernels from June 6 > > > and June 10 it's the other way round. > > > > > > > > > > > I'm confused :-) > > > > > > I can imagin - the complexity of acpi combined with Samsung's > > > implementation > > > and my imprecise description ... ;-) > > > > Our acpi code does something wrong. This seems to be the root cause > > of the acpitz(4) problems that we're seeing on a wider variety of > > hardware. I really think we should try to fix that broader issue > > before trying to fix this more specific suspend/resume issue on > > Samsung hardware. > > Sure. This is not at all urgent. It can wait for someone to fix > acpitz(4) on those machines. /me ducks :)
Re: acpiec(4): clear events based on vendor
On Wed, Jun 11, 2014 at 09:42:56PM +0200, Mark Kettenis wrote: > > Date: Wed, 11 Jun 2014 08:40:51 +0200 > > From: Remi Locherer > > > > On Wed, Jun 11, 2014 at 09:11:54AM +0300, Paul Irofti wrote: > > > On Tue, Jun 10, 2014 at 11:50:02PM +0200, Remi Locherer wrote: > > > > On Tue, Jun 10, 2014 at 06:25:33PM +0300, Paul Irofti wrote: > > > > > After discussions with Theo we decided to walk the table where needed > > > > > instead of using the soft state variables. > > > > > > > > > > Also adding all the Samsung models to the quirks table (as per the > > > > > Linux EC quirks table). > > > > > > > > > > > > > I tried this diff with my Samsung notebook. With sysctl hw.sensors or > > > > apm the state of the power supply is displayed correctly. If I change > > > > the > > > > status (disconnect or connect again) this is then also showed correctly. > > > > > > So this time it works... Did you apply the diff on top of a current sys? > > > > I did a cvs up on June 10 and applied this diff on top of that. > > > > > > > > > But a current kernel (checkout from June 10) with this patch applied > > > > does > > > > not show the acpibat0 sensor values correctly. > > > > > > And this time it does not? > > > > With this diff hw.sensors.acpiac0.indicator0 works correctly but > > hw.sensors.acpibat0.amphourX does not. With snapshot kernels from June 6 > > and June 10 it's the other way round. > > > > > > > > I'm confused :-) > > > > I can imagin - the complexity of acpi combined with Samsung's implementation > > and my imprecise description ... ;-) > > Our acpi code does something wrong. This seems to be the root cause > of the acpitz(4) problems that we're seeing on a wider variety of > hardware. I really think we should try to fix that broader issue > before trying to fix this more specific suspend/resume issue on > Samsung hardware. Sure. This is not at all urgent. It can wait for someone to fix acpitz(4) on those machines.
Re: acpiec(4): clear events based on vendor
> Date: Wed, 11 Jun 2014 08:40:51 +0200 > From: Remi Locherer > > On Wed, Jun 11, 2014 at 09:11:54AM +0300, Paul Irofti wrote: > > On Tue, Jun 10, 2014 at 11:50:02PM +0200, Remi Locherer wrote: > > > On Tue, Jun 10, 2014 at 06:25:33PM +0300, Paul Irofti wrote: > > > > After discussions with Theo we decided to walk the table where needed > > > > instead of using the soft state variables. > > > > > > > > Also adding all the Samsung models to the quirks table (as per the > > > > Linux EC quirks table). > > > > > > > > > > I tried this diff with my Samsung notebook. With sysctl hw.sensors or > > > apm the state of the power supply is displayed correctly. If I change the > > > status (disconnect or connect again) this is then also showed correctly. > > > > So this time it works... Did you apply the diff on top of a current sys? > > I did a cvs up on June 10 and applied this diff on top of that. > > > > > > But a current kernel (checkout from June 10) with this patch applied does > > > not show the acpibat0 sensor values correctly. > > > > And this time it does not? > > With this diff hw.sensors.acpiac0.indicator0 works correctly but > hw.sensors.acpibat0.amphourX does not. With snapshot kernels from June 6 > and June 10 it's the other way round. > > > > > I'm confused :-) > > I can imagin - the complexity of acpi combined with Samsung's implementation > and my imprecise description ... ;-) Our acpi code does something wrong. This seems to be the root cause of the acpitz(4) problems that we're seeing on a wider variety of hardware. I really think we should try to fix that broader issue before trying to fix this more specific suspend/resume issue on Samsung hardware.
