Messages in this thread |  | | Date | Sun, 7 Jun 2009 09:09:04 +0200 | From | Sam Ravnborg <> | Subject | Re: [GIT PULL] headers_check fixes |
| |
On Sun, Jun 07, 2009 at 12:24:15AM +0100, Russell King wrote: > On Sun, Jun 07, 2009 at 12:12:23AM +0200, Sam Ravnborg wrote: > > Hi Russell. > > > > On Sat, Jun 06, 2009 at 10:47:11PM +0100, Russell King wrote: > > > Right, below is a patch to unifdef.c which allows it to work out if > > > an #if expression always evaluates true or false for symbols which > > > are being undefined/always defined. > > > > > > The patch is slightly more complicated than I'd hoped because unifdef > > > needs to see lines fully evaluated - doing otherwise causes it to > > > mark the line as "dirty" and copy it over no matter what. > > > > > > What follows this email is the diff of what effect it has on the > > > headers copied over - as can be seen, all resulting changes are of > > > net benefit. > > > > You beat me on this one. > > I was looking into supportting short_circuit_and/short_circuit_or too. > > Your patch looks better - thanks! > > > > >From my very limited testing this patch suffers from a problem I faced too. > > When you run it on for example hwcap.h or my sample file: > > #if defined(__KERNEL__) && !defined(__ASSEMBLY__) > > int a; > > #endif > > > > then the return code of the program is 1 so we do not copy the file. > > That's correct. If unifdef removes any lines, the exit code is 1, not > zero. This happens with the unmodified unifdef as well, so I'm not > changing that behaviour.
Thanks. I was just fooled in my testing. With the same file I saw two different return codes with and without the patch. But this is because you fixed unifdef.
Sam
|  |