Hi David,
On 10/06/2025 14:19, David Brown wrote:
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.
There is often a good argument to be made for consistency. For example,
in a project that commonly uses the directive
#if defined(X) && defined (Y)
it could be annoying or confusing for one instance out of one hundred to
instead read
#if defined(Y) && defined(X)
However, nobody would seriously advocate that the order of operands to
&& should be enforced by the language. Instead, this is treated a matter
for coding standards, taste, and common sense. Some programmers care
about such things; others don't. It can also vary from project to
project. Having the compiler attempt to enforce someone's idea of "good"
style is a blunt instrument.
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.)
Assuming that enforcing an order is more complex than not enforcing it
(which seems likely, especially when taking into account the fact that
associated configuration might be needed to opt in or out), I think that
simplicity is a good enough reason in itself not to enforce the order.
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.
If anyone ever wants such a thing, I hope they come up with less subtle
syntax.
To be honest, I'm still not entirely comfortable with the fact that
these two commands have different effects:
cat a.txt >b.txt 2>&1
cat a.txt 2>&1 >b.txt
--
Christopher Bazley
Staff Software Engineer, GNU Tools Team.
Arm Ltd, 110 Fulbourn Road, Cambridge, CB1 9NJ, UK.
http://www.arm.com/
