Hacker News Reader

Comment by elcritch | Hacker News Reader

I like your version, but how do you annotate the size from existing things like "main(int *argv, argc)" to know that the size is argc?

View on HN

There was a proposal during the C23 process to make "main(int argc, char *argv[argc])" work as one would expect, as well as some similar changes elsewhere, such as with structure members. They went through several revisions but never made the cut, I think partially because they all required at least some minimal backward incompatibility.

IMO, if GCC or clang implemented and ran with those proposed changes, they'd probably be accepted for the next C revision, and become popular long before then. This is mostly a matter of time and motivation; corporate funded developer time seems to be mostly focused on half measures; e.g. type attributes, rather than fundamentally improving pointer and array semantics. But if someone put in enough time and effort, including going through the rigmarole of integration into mainline, this could happen.

"main(int argc, char *argv[argc])" should already work with C99, shouldn't it? Or was the proposal to make some of the VLA support mandatory again?

The syntax is accepted (almost as a fluke), but doesn't work the way anyone would expect because any use of argv still decays to a pointer, even with sizeof. That's in contrast to 'char *argv[argc]' declared as an automatic variable where sizeof computes at runtime the proper array size: 'sizeof (char *) * argc'.

The proposals would make function VLA syntax work the same as for automatic variables. In theory it could break existing code, but in practice nobody actually uses this in the wild because the semantics are useless and downright confusing. There's also a related proposal to enhance flexible array members in the manner of VLAs, e.g. 'struct foo { size_t n; int arr[n]; }'. IIRC, the latter syntax is accidentally supported by GCC as a side-effect of another extension, yet GCC wouldn't have minded breaking it even though there's more production code at risk than with the function argument change.

Create an adapter:

    int main(int argc, char **argv) { return myMain(argv[0 .. argc]); }

Strings can be done like this:

    char [..] s = p[0 .. strlen(p)];

Hmmm, the "[..]" is a fat pointer right? Couldn't you just say:

    int main(char [..] args)

Maybe with some way to tell the compiler the correct parameter order if needed? Perhaps:

    int main(char [..argc] argv)

I'm curious if ELF and other formats have enough info to figure that mapping out?

> the "[..]" is a fat pointer right?

yes

> if ELF and other formats have enough info to figure that mapping out?

No, as there is no semantic connection between `argc` and `argv`.

You just... annotate it? Like, I don't see what the issue is. You just write

    int main(int argc, char **argv : count(argc)) {}

If you're already creating an extension for C, then it's fine to "change" its signature in this way. Or am I misunderstanding your objection?

Sure, the compiler can't verify that argv does indeed have argc elements, but hopefully we can rely on the kernel and C runtime to populate things properly. If not, I would say it doesn't matter that the compiler can't help you here; your system is screwed beyond repair already.

At the very least, the compiler can emit bounds checking to ensure that you don't try to access past argc elements in that array, which is still valuable.

Edit: it occurs to me that you were talking about WalterBright's version, not the version in Checked C. But I think my comment still applies: if you're changing how things work, then you just keep changing how things work to cover cases like this.

Reply on news.ycombinator.com