linux-kernel - Re: [PATCH 1/1] unifdef.c change "getline" to "get

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] [day] [month] [year] [list]

Message-ID: <dd18b0c30903050942w362a82d8pb9a945e7fb3ccad8@mail.gmail.com>
Date:	Thu, 5 Mar 2009 09:42:48 -0800
From:	Justin Mattock <justinmattock@...il.com>
To:	Randy Dunlap <randy.dunlap@...cle.com>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mike Frysinger <vapier@...too.org>
Subject: Re: [PATCH 1/1] unifdef.c change "getline" to "get_line" to avoid C 
	library confusion.

On Thu, Mar 5, 2009 at 7:33 AM, Randy Dunlap <randy.dunlap@...cle.com> wrote:
>> From: Justin P. Mattock <justinmattock@...il.com>
>> Signed-off-by: Justin P. Mattock <justinmattock@...il.com>
>>
>> This fixes an error when compiling the kernel.
>
> Did you determine why you need this now and other people don't
> need it (yet)?  Maybe the rest of us will need it in the future...
>
>
>>  CHK     include/linux/version.h
>>  HOSTCC  scripts/unifdef
>> scripts/unifdef.c:209: error: conflicting types for 'getline'
>> /usr/include/stdio.h:651: note: previous declaration of 'getline' was here
>> make[1]: *** [scripts/unifdef] Error 1
>> make: *** [__headers] Error 2
>>
>> --
>> scripts/unifdef.c  |  3 +++
>> 1 files changed, 3 insertions(+),0 deletions(-)
>>
>> ---a/scripts/unifdef.c                2009-03-05 00:07:28.000000000 -0800
>> +++b/scripts/unifdef.c        2009-03-05 00:04:56.000000000 -0800
>> @@ -206,7 +206,7 @@ static void             done(void);
>>  static void             error(const char *);
>>  static int              findsym(const char *);
>>  static void             flushline(bool);
>> -static Linetype         getline(void);
>> +static Linetype         get_line(void);
>>  static Linetype         ifeval(const char **);
>>  static void             ignoreoff(void);
>>  static void             ignoreon(void);
>> @@ -512,7 +512,7 @@ process(void)
>>
>>       for (;;) {
>>               linenum++;
>> -             lineval = getline();
>> +             lineval = get_line();
>>               trans_table[ifstate[depth]][lineval]();
>>               debug("process %s -> %s depth %d",
>>                   linetype_name[lineval],
>> @@ -526,7 +526,7 @@ process(void)
>>   * help from skipcomment().
>>   */
>>  static Linetype
>> -getline(void)
>> +get_line(void)
>>  {
>>       const char *cp;
>>       int cursym;
>>
>>
>
>
> --
> ~Randy
>

As for why I need this:
I keep getting an error while compiling the latest kernel.
(changing getline to get_line fixes it from here);

As for others needing this:
probably in the category for future use.
especially if people don't upgrade there kernel
and libc.

In speculation though, people may never hit this.
The setup I did was created an LFS system(always wanted to create a
linux system from source).
While creating this starting with a plain directory,
then compiling make, gcc, libc, making sure to set CFLAGS,
(in accordance to the processor)
then after those were complete, set the same
CFLAGS for every lib/app that I compiled and put into the system.
(this way the system is atomically synchronized with the processor);
Thus changing the whole setup that I have.
But then If this was the case I would of hit this probably earlier
with 2.6.29-rc4/5.

In regards to the patch(to make things correct) what or how do I
label this person in the patch so they get the proper credit:
vapier@...too.org
They were responsible with providing the change
of getline to get_line.
should it be:
Critical-info-by: Mike Frysinger  <vapier@...too.org>

And also adding the people who reviewed the patch.
This way the patch is proper irregardless of the patch making it
or not.

regards;

-- 
Justin P. Mattock
--
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/