linux-kernel - Re: [kbuild-devel] [PATCH 25/33] kbuild: use POSIX BRE in headers install target

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8bd0f97a0707210127m565f9b2cnc7a8a203f671e948@mail.gmail.com>
Date:	Sat, 21 Jul 2007 04:27:31 -0400
From:	"Mike Frysinger" <vapier.adi@...il.com>
To:	"Oleg Verych" <olecom@...wer.upol.cz>
Cc:	"Sam Ravnborg" <sam@...nborg.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	kbuild-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [kbuild-devel] [PATCH 25/33] kbuild: use POSIX BRE in headers install target

On 7/21/07, Oleg Verych <olecom@...wer.upol.cz> wrote:
> * Date: Tue, 17 Jul 2007 16:08:54 +0200
> >
> > From: Mike Frysinger <vapier@...too.org>
> >
> > The sed expression used at the moment in scripts/Makefile.headersinst
> > relies on the (handy) GNU extension where you can escape ERE's in an
> > otherwise BRE without using the GNU -r option.  The following patch
> > replaces this "\+" usage with a functionally equivalent POSIX BRE compliant
> > "\{1,\}".
>
> Matching at least one occurrence, right?

that is the definition of both + and \{1,\}

> >  # Eliminate the contents of (and inclusions of) compiler.h
>
> OK, that means annotations and non ANSI 'inline' thing. Lets see.
>
> >  HDRSED  := sed       -e "s/ inline / __inline__ /g" \
> []
> > -             -e "s/[[:space:]]__attribute_const__[[:space:]]\+/\ /g" \
>
> * [[:space:]] are more than tab and space isspace(3), is it more
>   effective to use [[:blank:]] instead?

if you want to make some micro optimization in the build install step,
sure ... but functionally, the difference is irrelevant considering
sed operates only on individual lines

> > +             -e
> > "s/[[:space:]]__user[[:space:]]\{1,\}
>
> substitute one or more ' __user '
>
> > / /g" \
>
> with ' ', everywhere (flag 'g'). So, is it really needed that '\{' thing?

no, there is no grouping marker anywhere, so the match always applies
to just the whitespace

> > +             -e "s/(__user[[:space:]]\{1,\}/ (/g" \
> > +             -e "s/[[:space:]]__force[[:space:]]\{1,\}/ /g" \
> > +             -e "s/(__force[[:space:]]\{1,\}/ (/g" \
> > +             -e "s/[[:space:]]__iomem[[:space:]]\{1,\}/ /g" \
> > +             -e "s/(__iomem[[:space:]]\{1,\}/ (/g" \
> > +             -e "s/[[:space:]]__attribute_const__[[:space:]]\{1,\}/\ /g" \
> >               -e "s/[[:space:]]__attribute_const__$$//" \
>
> Is it allowed to use identifiers like '__attribute_const__foo' or
> __attribute_const__[anything]? If it's not, last line is useless also.

a question that i think is really only relevant if it actually occurs
in the source code

> >               -e "/^\#include <linux\/compiler.h>/d"
> whitespace is allowed   ^ here and is used for better readability
> sometimes.

so post a patch for inclusion ... not that it's been an actual problem
[yet] though
-mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/