Author Topic: Overwriting fields in init struct.  (Read 42 times)

lerno

  • Full Member
  • ***
  • Posts: 211
    • View Profile
Overwriting fields in init struct.
« 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,
};

bas

  • Full Member
  • ***
  • Posts: 205
    • View Profile
Re: Overwriting fields in init struct.
« Reply #1 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.

lerno

  • Full Member
  • ***
  • Posts: 211
    • View Profile
Re: Overwriting fields in init struct.
« Reply #2 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?

bas

  • Full Member
  • ***
  • Posts: 205
    • View Profile
Re: Overwriting fields in init struct.
« Reply #3 on: November 29, 2018, 08:26:05 AM »
Which unit test?

lerno

  • Full Member
  • ***
  • Posts: 211
    • View Profile
Re: Overwriting fields in init struct.
« Reply #4 on: November 29, 2018, 02:45:24 PM »
/Init/init_field_designator_duplicate.c2

bas

  • Full Member
  • ***
  • Posts: 205
    • View Profile
Re: Overwriting fields in init struct.
« Reply #5 on: November 30, 2018, 01:19:43 PM »
Why would this not be an error?

lerno

  • Full Member
  • ***
  • Posts: 211
    • View Profile
Re: Overwriting fields in init struct.
« Reply #6 on: November 30, 2018, 06:37:46 PM »
Motivation why it should be allowed is in the first post...

bas

  • Full Member
  • ***
  • Posts: 205
    • View Profile
Re: Overwriting fields in init struct.
« Reply #7 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..

lerno

  • Full Member
  • ***
  • Posts: 211
    • View Profile
Re: Overwriting fields in init struct.
« Reply #8 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!