Hacker News Reader

> Very confused by this. The C code declares an anonymous struct type, then aliases the typename "Foo" to that anonymous struct type. The C3 code seems to declares a named struct type "Foo" -- why isn't the C equivalent here just "struct Foo"?

I'm curious how familiar you are with C? In C++ you can do:

  struct Foo {
    // ...
  };
  Foo myVar;

But that's not how it works in C. In C this would be:

  struct Foo {
    // ...
  };
  struct Foo myVar;

Which is why many C developers typedef the struct so that they don't have to prefix struct types with the keyword.

> I don't think I can get further into the primer than this... even taking the author at their word that the two snippets are equivalent

Maybe don't judge the author on these things if you're not familiar with how C would work in this case? There's nothing wrong with not understanding a piece of code, but it's generally not a good idea to assume you have understanding of a language like C if you understand C++. People often conflate the two, but there are many quirks of C that C++ doesn't necessarily need to do and vice versa.

I hate when c++ does this. I don't want automatic typedefs, keep the struct so I know what it is. Also causes annoying name conflicts ...

The number of languages that have separate namespaces for the two things is very small. See all the C descendants that discarded that idea: C++, C#, Java, Rust, Go. You probably ought to just find a decent naming scheme to avoid those conflicts…

I can’t speak for the others, but Rust definitely has separate namespaces for them. See https://doc.rust-lang.org/beta/reference/names/namespaces.ht...

Not the type of namespace being referred to. In this case, it's referring to the requirement to refer to all types of a certain category with a keyword, as in `struct Foo`. In Rust, you can refer to a struct named Foo as just `Foo`.

I disagree. There may not be a keyword required to refer to `struct`s specifically, but the namespace that is searched when resolving a symbol is determined by the syntax used to refer to it. For example, in C++, you cannot determine whether `a` is a type or a value in the statement `a * b;` without knowing how it is declared, and C also has this ambiguity once `typedef`s are involved. In Rust, there are no such ambiguities (unless there's something I've missed).

C++ didn't discard that idea entirely, you can have a struct tag and a function with the same name and you need to be able to do that in order to use stat().

Why would you want to expose implementation details?

c++ just understands that the only purpose you could e using it for is "struct foo". if you have a function "int foo()" as well, then you'll still need the struct tag(which really is necessary because you can do things like call structs like functions)

> Which is why many C developers typedef the struct so that they don't have to prefix struct types with the keyword.

Oh, hello. Yes, guilty.

Wrapping structs in typedefs like this should be a distant and quaint memory by now. C'mon guys its 2022. Why hasn't some standard gotten rid of this requirement for typedefs around structs?

Deprecate this requirement already and make it an option. Gcc --stupid-typedef-required

Edit: or stated in another way, please describe the good reason(s) for having typedef struct {} Foo in C. Do it in terms of justifying the extra typing / extra steps. I'd really like to know. This is extra code and one more thing to test and confirm. Don't reference history or "its just how its always been done" - that to me is an admisson that it needs to go into an option. Also you'll need to explain why its bad that C++ doesn't require this. I'd also like to see as part of this rebuttal a formal statement that C++ got it completely wrong.

So: Why in C do we require the extra steps just so we can get rid of the struct keyword having to be plastered everywhere?

Personally I think the typedef struct pattern is kept purely for historical reasons and is no longer necessary. It obscures the code rather than clarifies it. There are much better reasons for using typedef but getting rid of "struct" prefixes everywhere isn’t one of them.

https://www.kernel.org/doc/html/v4.10/process/coding-style.h...

If you can't figure out what vps_t means in your codebase then you have much much bigger issues than typedefs.

Changing it would break existing code. In C, types "A" and "struct A" could have been defined as completely different types.

Sounds like: We've always done it this way. Often rephrased as: Its not possible to write a script to fix this. We can't have automated tests. There's no way we can find all the places this is likely to be used. There's no way to do this at all because insert-authority-figure's-opinion. Oh no! But really its all historical rather than a real issue.

Its just a code smell. There are likely other bugs hiding around the code. Business logic issues as well. Overall its a story of generally poorly written and ambiguous code. So... Perhaps fix it?

If you can't fix it then a compiler option would do it.

That's a strawman. The reason is the option would break code due to C's semantics, in the best case it would fail to compile, and in the worst case it would still compile but change what the code did.

What you're asking for is equivalent to changing the semantics of the language, which is frankly untenable for C.

I'll leave it there. I respectfully agree to disagree. What to you looks like a strawman is for us a signpost towards identifying a module that needs linting and code review. Code that cannot handle that typedef change? Yeah it needs review. What other issues are hiding in there? Oh wait what have they been doing with the preprocessor?

The codebases we work on are from the 1980s. They sorely need to be dragged kicking and screaming if necessary to later standards. So many warts. People abused the preprocessor like it was normal and expected.

The semantic change isn’t as big as you'd expect. Even as it is in fact a semantic change. But I sense significant gatekeeping as well to hold back the tide.

Oh gosh... digging further on the same page under "Identifiers" it looks like case sensitivity is the key here. So "struct Foo" declares a type "Foo", and "struct foo" declares a variable "foo" of new anonymous type. I assume "struct Foo foo" and "struct bar Bar" do exactly what you (don't) expect, and maybe even "struct foo bar baz {}" to be the equivalent of the C code "struct {} foo, bar, baz"... yikes.

Edit: "Declaring more than one variable at a time is not allowed." So there's no equivalent to the C code ""struct {} foo, bar, baz"... not clear if "struct IDontNeedANameButTheLanguageIsForcingMe foo {}; IDontNeedANameButTheLanguageIsForcingMe bar; IDontNeedANameButTheLanguageIsForcingMe baz;" is legal (modulo that some of those semicolons are illegal I think?).

Yeah, this needs some rigor in the docs.

This doesn't seem very well thought out at all

No, you misunderstand. There is no `struct Foo foo`. Unlike C `struct Foo` would only ever be valid at the top level. Neither `struct Foo foo` nor `struct bar Bar` works.

The reason why `Bar` is a type and `bar` is a variable or function is to resolve the ambiguity of C syntax without having to rely on unlimited lookahead or the lexer hack. Basically it allows tools to parse the code much more easily than they would C.

You can declare multiple fields in a struct, e.g. `struct Foo { int x, y; }`, but you can't write `int x, y = 123;` like in C. This is because it would create ambiguities in the extended for/while/if syntax C3 adds.

> why isn't the C equivalent here just "struct Foo"?

That would not be the equivalent... you would then need to declare the type of Foo variables as:

    struct Foo myVar;

With the typedef, and I assume with C3, you would do the more acceptable:

    Foo myVar;

From the primer, C3 follows the C++ rules here, not C rules. Changing to using C++ struct/enum/union naming rules here is a much less invasive change than what I'm discussing.

The first part about the name is just like C++: you use the name without `struct` unlike C where structs has its own namespace. That's what it's meant to illustrate.

The second question is more subtle. In C, the syntax is `struct { ... } [optional member name] ;`. Because there is no anonymous struct at the top level, the anonymous structs inside of a struct has a different syntax, also eschewing the final `;`, changing the syntax to `struct [optional member name] { ... }`. If the C syntax structure is desired a final `;` would be required. This syntax change comes from C2.

But what if I want to name the inner struct so I can refer to Outer::Inner (for example, for use with sizeof or similar, or to create a temporary to hold a copy of that type) later? Do I need to use typeof(Outer::inner)? And then of course multiple members of the same type...

You can't name the inner struct. So here are the options:

Say that you want this from C:

    struct Foo
    {
      struct Bar {
        int x;
        int y;
      } bar;
    };
    struct Foo f;
    f.bar = (struct Bar) { .x = 123 };

The struct in C3:

    struct Foo
    {
      struct bar {
        int x;
        int y;
      }
    };
    Foo f;

It is correct that we don't get the inner type, but because C3 has inference for {} assignment can happen despite that:

    f.bar = { .x = 123 }; // Valid in C3

You can grab the type using typeof if you want, but interestingly there's also the possibility to use structural casts, which are valid in C3:

    struct HelperStruct
    {
      int x;
      int y;
    }
    HelperStruct test = (HelperStruct)f.bar; // structural cast

But the normal way would be to create a named struct outside if you really need a named struct, e.g.:

    struct Bar { int x, y; }
    struct Foo
    {
      Bar bar;
    };

That ... actually seems reasonable?

If you need it to be first class visible outside, you declare it outside.

I believe I could live with this.

Also, just to be clear, the removal of semicolons deliberately makes the language whitespace sensitive, right? That is,

    struct Foo {
    } foo

declares a variable of a new empty struct type, but

    struct Foo {}
    foo

is a syntax error?

C3 doesn't have declaration of structs/unions in variable declarations. So both are equivalent and are syntax errors.