On 10/06/2025 10:43, Jakub Jelinek wrote:
On Tue, Jun 10, 2025 at 09:52:42AM +0200, David Brown via Gcc wrote:
So while correcting the mistakes of the past is either very slow or
impossible, we can avoid them in the future. Consistent parameter order
makes code clearer and neater, and should be encouraged.
For context here, I am a C and gcc user, not a developer of either the
compiler or libraries. That means I have no direct influence on any of
this, and I do not have nearly as wide an experience with different C
developers and different C code as many of the others here - my
experience is focused on small-systems embedded development. So that
means my thoughts or opinions here might be very skewed, and not very
applicable to the wider world of C. I give my thoughts here in the hope
that they might be useful, but I am fully aware that I can be missing
some of the big picture.
If the clauses are properly documented, enforcing some order is just a
hassle to users who will need to remember the ordering (which won't be
obvious).
I disagree. Obviously I agree that proper documentation is good. But I
think enforced order can be very useful too. This is particularly
important for new or rarely-used features of a language. Having an
enforced order can actually mean one /less/ thing for people to learn -
not /more/ for them to remember. It means when they look at examples or
other people's code, which is one of the main ways people learn about
new features (very few C programmers actually read the standards or
reference resources like en.cppreference.com), the existing code is more
consistent. No one has to wonder why people have used different
orderings, or what difference it makes.
The #embed parameters are really similar to OpenMP/OpenACC clauses
and those haven't enforced any particular ordering for 25+ years (the only
exception are unnamed clauses that on certain directives must appear first
followed by other clauses).
I don't think that is a good argument unless you have reason to say that
the flexibility of ordering was a good thing in OpenMP clauses, and can
show that code is clearer, safer, more efficient, easier to maintain, or
otherwise "better" as a result of people being able to use different
orders of parameters in OpenMP clauses. If you have reason to believe
that flexible ordering lets people write better code OpenMP code, and
that the same effect will let people write better #embed code, then
that's fair enough - and good reason to copy that practice. But the
precedence alone is not a strong reason. (It's maybe strong enough if
you think it really doesn't matter whether there is an order or not to
the #embed parameters.)
The limit/offset clauses are handled at a different time during
preprocessing than if_empty/prefix/suffix, the former to find out what part
of data if any will be read from the file (if it exists), the latter when
the directive is being replaced by new tokens.
Having the clauses ordered that way then makes more sense to me.
Making the order relevant would also make the whole thing more flexible
for future enhancements - in the future, someone might be interested in
adding filtering or transformation parameters. (In C++, that could
always be done with constexpr functions and ranges, but C does not have
these.) But maybe that idea is going too far beyond the scope of #embed.
David
Whether limit (0) actually affects what if_empty/prefix/suffix clauses
will do depends on if the resource is empty or not, and limit with non-zero
size will never affect it. offset clause will affect those only if it is
larger or equal than the file size.
Jakub
