C2 forum

General Category => General Discussion => Topic started by: lerno on November 18, 2018, 04:11:57 PM

Title: Overwriting fields in init struct.
Post by: lerno on November 18, 2018, 04:11:57 PM

In this article:

https://lwn.net/Articles/444910/

The following method is discussed for setting better defaults of vtables than having NULL in C for the Linux kernel:

Code: [Select]

#define FOO_DEFAULTS  .bar = default_bar, .baz = default_baz
struct foo_operations my_foo = { FOO_DEFAULTS,
  .bar = my_bar,
};

The usefulness here is that having a meaningful default method, the test for NULL can be avoided. So instead of:

Code: [Select]

if (my_foo.bar != NULL) my_foo.bar();

We can simply use:

Code: [Select]

my_foo.bar();

Since the default method is assumed to be correct for the situation.

Currently in C2, this would not be possible. While I understand the need to "error proof" things, I think this should not be forbidden in C2, and instead produce a warning that can be supressed using an @(override), like this:

Code: [Select]

#define FOO_DEFAULTS  .bar = default_bar, .baz = default_baz
Foo_operations my_foo = { FOO_DEFAULTS,
  .bar = my_bar @(override),
};

OR by setting a @(weak) on the default:

Code: [Select]

#define FOO_DEFAULTS  .bar = default_bar @(weak), .baz = default_baz @(weak)
Foo_operations my_foo = { FOO_DEFAULTS,
  .bar = my_bar,
};


Title: Re: Overwriting fields in init struct.
Post by: bas on November 27, 2018, 09:58:32 AM

This depends completely on the situation. For some file_operations in linux, this might be a good option, but for generic
code, there are no good 'defaults' imho. What C2 did change already is to guarantee that every global is always initialized
by default. This avoids some silly mistakes.

Title: Re: Overwriting fields in init struct.
Post by: lerno on November 27, 2018, 02:42:24 PM

Should the error on overwriting fields in init struct stay? Or just a warning that can be overridden?

Title: Re: Overwriting fields in init struct.
Post by: bas on November 29, 2018, 08:26:05 AM

Which unit test?

Title: Re: Overwriting fields in init struct.
Post by: lerno on November 29, 2018, 02:45:24 PM

/Init/init_field_designator_duplicate.c2

Title: Re: Overwriting fields in init struct.
Post by: bas on November 30, 2018, 01:19:43 PM

Why would this not be an error?

Title: Re: Overwriting fields in init struct.
Post by: lerno on November 30, 2018, 06:37:46 PM

Motivation why it should be allowed is in the first post...

Title: Re: Overwriting fields in init struct.
Post by: bas on December 07, 2018, 10:26:35 AM

I think this is again a situation that does make the language a bit more complex, while not adding much.
Let's really keep the language as simple as possible. That way, (extra) tooling could add warnings for
unset functions more easily..

Title: Re: Overwriting fields in init struct.
Post by: lerno on December 07, 2018, 11:05:24 AM

I am concerned over the fact that we're excluding an important feature that's used in the linux kernel. I would actually claim that we're *not* adding much complexity, since we can actually prune this in the parsing step already!

Title: Re: Overwriting fields in init struct.
Post by: bas on December 16, 2018, 10:51:20 AM

I'll have to think about this.. I've put in on the Wiki Roadmap so we don't forget.

I did some searching in the kernel code, but couldn't find actual usages. I've done quite some kernel work also
and never actually saw this in use.

Title: Re: Overwriting fields in init struct.
Post by: lerno on December 16, 2018, 07:28:51 PM

Weren't there any links in that article?