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:   Tue, 5 Oct 2021 16:37:54 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Jan Engelhardt <jengelh@...i.de>
Cc:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Paul <paulmck@...ux.vnet.ibm.com>,
        Josh Triplett <josh@...htriplett.org>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        "Joel Fernandes, Google" <joel@...lfernandes.org>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        Jozsef Kadlecsik <kadlec@...filter.org>,
        Florian Westphal <fw@...len.de>,
        "David S. Miller" <davem@...emloft.net>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        David Ahern <dsahern@...nel.org>,
        Jakub Kicinski <kuba@...nel.org>, rcu <rcu@...r.kernel.org>,
        netfilter-devel <netfilter-devel@...r.kernel.org>,
        coreteam <coreteam@...filter.org>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [RFC][PATCH] rcu: Use typeof(p) instead of typeof(*p) *

On Tue, 5 Oct 2021 15:40:29 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:

> struct trace_pid_list {
> 	unsigned long		ignore;
> };
> 
> Rename the above struct trace_pid_list to struct trace_pid_internal.
> 
> And internally have:
> 
> union trace_pid_data {
> 	struct trace_pid_list		external;
> 	struct trace_pid_internal	internal;
> };
> 
> Then use the internal version within the C file that modifies it, and just
> return a pointer to the external part.

So this has proved to be a PITA.

> 
> That should follow the "C standard".

Really, thinking about abstraction, I don't believe there's anything wrong
with returning a pointer of one type, and then typecasting it to a pointer
of another type. Is there? As long as whoever uses the returned type does
nothing with it.

That is, if I simply do:

In the header file:

struct trace_pid_list {
	void *ignore;
};

struct trace_pid_list *trace_pid_list_alloc(void);
void trace_pid_list_free(struct trace_pid_list *pid_list);


And then in the C file:

struct pid_list {
	[...]
};

struct trace_pid_list *trace_pid_list_alloc(void)
{
	struct pid_list *pid_list;

	pid_list = kmalloc(sizeof(*pid_list), GFP_KERNEL);
	[..]

	return (struct trace_pid_list *)pid_list;
}

void trace_pid_list_free(struct trace_pid_list *list)
{
	struct pid_list *pid_list = (struct pid_list *)list;

	[..]
	kfree(pid_list);
}

That should be perfectly fine for standard C. Right?

-- Steve

Powered by blists - more mailing lists