linux-kernel - Re: [PATCH] trivial

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]

Date:	Fri, 31 Aug 2007 02:11:14 +0530 (IST)
From:	Satyam Sharma <satyam@...radead.org>
To:	Jan Engelhardt <jengelh@...putergmbh.de>
cc:	Alexey Dobriyan <adobriyan@...il.com>,
	Joe Perches <joe@...ches.com>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] trivial - constify sched.h

On Thu, 30 Aug 2007, Jan Engelhardt wrote:
> 
> On Aug 28 2007 01:33, Alexey Dobriyan wrote:
> >
> >On Mon, Aug 27, 2007 at 01:40:31PM -0700, Joe Perches wrote:
> >> Add const to some struct task_struct * uses
> >
> >Why, oh, why?
> 
> 
> So that you can actually pass in a const struct task_struct * without having
> to cast it back to [non-const].

... which makes zero sense, because ...

> Why one would have a const struct task_struct * in the first place
> is a different matter.

... exactly.

> But see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=77adbfbf4cf96fedf9b75bb330704828c187b190

That commit const-ified struct timespec * or struct timeval * arguments,
which made sense because: (1) those functions really did not modify the
passed structs, and, (2) callers that pass in const struct timeval *
or const struct timespec * are indeed plausible (because one can plausibly
have const timeval/timespec structs). As the changelog suggested, those
callers were having to cast away the const qualifier before passing to
these functions to avoid seeing "passing argument discards qualifiers"
warnings. While (1) holds true for the sched.h case here, (2) does not
(and there are no warnings to shut up either).

If one really wants to go about "constifying" the kernel, then I think
there's a lot of _data_ out there that should first be made const-
qualified. xxx_ops function tables, and the like.
-
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/