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: <alpine.LFD.0.999.0708310121121.28360@enigma.security.iitk.ac.in>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ