Re: [kconfig] results of some syntactical checks

[Martin Walch]

On Wednesday 17 July 2013 01:18:00 Paul Bolle wrote:
> On Wed, 2013-07-17 at 00:34 +0200, Martin Walch wrote:
> > As I am working on yet another project for analyzing LKC's input files, I
> > have some intermediate results from simple syntactical checks.
> 
> Naive question: LKC?

Sorry, I thought the abbreviation of the kconfig system "LinuxKernelConf" was 
common.

> > The results below are an excerpt from a run against tche current master.
> 
> One thing I noticed is that it is practical to be able to parse
> arbitrary tags (commits) in the git tree. So you can quickly parse a
> tree you don't actually have checked out in git. But perhaps your
> checker also does that.

Actually no, it does not. So far, a tree has to be checked out and a branch 
has to be manually selected.

> > Actually defined symbols with dangerous names: 2
> > 
> >   8260 at
> >   
> >     arch/powerpc/platforms/82xx/Kconfig:55:0
> >   
> >   8272 at
> >   
> >     arch/powerpc/platforms/82xx/Kconfig:64:0
> 
> I've wondered for some time what happens when one uses either of these
> numbers as the value for an "int" Kconfig symbol. I've never tried.

I would not expect anything bad to happen when the user manually assigns a 
value like 8260. However, it can break a range value like this:

config FOO
        int "FOO"
        range 8260 8272

On ARCH=powerpc, this will effectively make LKC print a warning "range is 
invalid" and pin down the value of FOO to 0.

Similar problems occur with default values:

config FOO
        int "FOO" if n
        default 8260

This will raise a warning "'FOO': number is invalid" and default FOO to 0.

No warning will show up if the symbol with the integer name would be actually 
an int:

config 4711
        int "4711"

config FOO
        int "FOO" if n
        default 4711

In this case, FOO will be set to whatever 4711 is set to.

All this can be avoided by quoting values, i. e.

	range "8260" "8272"

and

        default "4711"

Also, avoiding integers (and hex values) as symbol names looks like a 
reasonable idea.

> >   Symbol: PLATFORM_MICROBLAZE_AUTO at
> >   
> >     arch/microblaze/platform/Kconfig.platform:10:0
> 
> This is a default of a "choice". There used to be quite a lot of invalid
> "choice" defaults, so I stopped checking those. (But I didn't bother to
> look how my local script now handles these.) In practice these are
> treated as "no default", aren't they?

As far as I can tell, yes. Such a default line will be basically just ignored.


On Wednesday 17 July 2013 08:30:58 Paul Bolle wrote:
> > My script currently finds 28 undefined symbols. That equals this result
> > (given you have 2 false positive and 1 undefined choice default.)
> 
> So those 2 were actually correct positives.

I am glad that our results match. So they are presumably correct.
--

Attachment: signature.asc
Description: This is a digitally signed message part.