Hi,
Thenk you for very prompt reply.
W dniu 13.09.2021 o 10:44, Jonathan Wakely pisze:
> On Mon, 13 Sept 2021 at 07:55, Rafał Pietrak via Gcc <gcc@gcc.gnu.org> wrote:
[-----------------]
>> #elif VARIANT_WORKING
>> struct cr_s a = (struct cr_s) {
>> .re = 1,
>> .te = 1,
>> .rxneie = 1,
>> .txeie = 1,
>> .ue = 1 };
>> int *b = (int *) &a;
>> d->cr1 &= ~(*b);
>
> This is a strict aliasing violation. You should either use a union or
> memcpy to get the value as an int.
Yes, I know. I know, this is a "trick" I use (I had to use to missleed
gcc).
I've put it here as an example of something, that allows me to get the
very same binary output as the "traditional" coding, .... while (IMHO)
improving readability of the code.
[--------------]
>> In function EXIT, you can see four variants of "the same code". First
>> fragment is codded just like todays common practice is. This is BAD
>> coding, because debugger has no way of presenting "the real thing".
>
> Have you tried -ggdb3 which does preserve macro information?
No. I'll check it out. Thenx. Still, gdb translation of macros is just
one of the problems with traditioonal coding (explanation followes).
[------------]
>> Then again, it would be even better (and easier to read the code),
>> should gcc syntax parser recognised VARIANT_BETTER or VARIANT_THE_BEST
>> as "syntactic sugar" to generate code, that currently gets issued by
>> VARIANT_WORKING (being the same as issued by VARIANT_TRADITIONAL, which
>> is very OK).
>
> You can define an inline function that initializes the struct, then
> returns the negation of the int value.
Hmmm. probably yes. But this will only obfuscate the code. I'm trying to
say here, that part of the consequence of missing support for constructs
like VARIANT_THE_BEST, is that todays coding practice is exactly like
this. Meaning: people are doing those inline functions, and to be able
to distinguish them, call them like:
[now_lets_disable_receiving_register()] .... which in reality is putting
a comment into function name. IMHO - a bad thing. A comment is a comment.
I hopped, that support for direct (explicit) struct operations like in
my example, could ultimately streighten the practice. But I can see from
your reply that there is very little chance of that.
>
> I very much doubt GCC will add an extension to make ~ work on structs.
> What would it even mean if sizeof(struct cr_s) == 3 or == 1024?
And that's a very good point. ... and in favor of my arguments.
The [struct cr_s] is defined in CPU documentation: it is, and it must be
4. Should a programmer make a typo declaring the struct, a typo which
would result in such sizeof mismatch, the compiler could raise an alarm.
With the proposed construct, the compiler can do that. That's very
desirable. And I'm speaking from experience. I did have this sort or
errors myself, and VARIANT_TRADITIONAL allowed me that without a glitch.
But if nothing can be done, that's life. Thank you anyway.
with best regards,
-R
