Ticket #45159

generate_packets.py: Self-comparisons in the generated code

Eröffnet am: 2022-07-19 21:28 Letztes Update: 2022-07-22 20:54

Auswertung:
Verantwortlicher:
Typ:
Status:
Geschlossen
Komponente:
Meilenstein:
Priorität:
5 - Mittel
Schweregrad:
5 - Mittel
Lösung:
Gefixt
Datei:
2

Details

packets_gen.c has a lot of self-comparisons. Haven't looked at how hard it would be to generate the code without them (+ not introducing other compiler warnings, like 'unused variable', in the process).

First one that comes up with current master:

packets_gen.c:6145:20: warning: self-comparison always evaluates to false [-Wtautological-compare]
differ = (O_LAST != O_LAST);

Ticket-Verlauf (3/11 Historien)

2022-07-19 21:28 Aktualisiert von: cazfi
  • New Ticket "generate_packets.py: Self-comparisons in the generated code" created
2022-07-19 21:39 Aktualisiert von: alienvalkyrie
Kommentar

Yeah, I'd noticed that (relevant Python code is in Field.get_cmp(), toward the bottom where arrays are handled); main reason I haven't looked at changing it yet is that it will probably be less work after everything else is restructured. But it should be relatively easy to fix; would probably end up very similar to how Field.get_get_real() only conditionally emits the code that checks for array truncation.

One thing to think about is that these comparisons are immediately followed by if (!differ), so when replacing them with differ = FALSE; (which must not be omitted), it would be possible (and maybe necessary, to avoid warnings?) to get rid of that if as well (but its block must remain a block, since it declares variables).

2022-07-21 01:45 Aktualisiert von: alienvalkyrie
  • Verantwortlicher Update from (Keine) to alienvalkyrie
  • Lösung Update from Keine to Accepted
  • Meilenstein Update from (Keine) to 3.2.0
Kommentar

Decided to do it now, since it's a very small change and doesn't actually require any serious kludge (get_cmp() has only one array case).

2022-07-21 02:07 Aktualisiert von: cazfi
Kommentar

Reply To alienvalkyrie

Decided to do it now, since it's a very small change and doesn't actually require any serious kludge (get_cmp() has only one array case).

Is that only after all the refactoring you have already done, or could we have it also for older branches? (would potentially save some effort on whitelisting / filtering out / silencing errors from the generated file on all kind of build test environments)

2022-07-21 02:12 Aktualisiert von: alienvalkyrie
Kommentar

Reply To cazfi

Is that only after all the refactoring you have already done, or could we have it also for older branches? (would potentially save some effort on whitelisting / filtering out / silencing errors from the generated file on all kind of build test environments)

It would certainly require a separate patch, but it shouldn't be difficult to whip one up. A bit ugly perhaps, but not difficult.

2022-07-21 02:24 Aktualisiert von: alienvalkyrie
Kommentar

Reply To alienvalkyrie

it shouldn't be difficult to whip one up. A bit ugly perhaps, but not difficult.

Nevermind; it is more difficult, and the best solution I can come up with is pretty damn ugly. What scale of "some effort ... on all kind of build test environments" are we talking about here?

2022-07-21 02:37 Aktualisiert von: alienvalkyrie
Kommentar

Found a less ugly way to do it by basically backporting one of the intermediate cleanup steps along with it.

2022-07-21 03:35 Aktualisiert von: cazfi
Kommentar

Reply To alienvalkyrie

What scale of "some effort ... on all kind of build test environments" are we talking about here?

Predicting future to answer that ... isn't easy. At the moment the only issue I have is that on github runner mac/homebrew/meson/-Ddebug=true (-> -Werror) build fails, which I've resolved by building -Ddebug=false for now (obviously meaning that *all* the warnings would get unnoticed if it goes to CI like that). However, this is likely just indicative that newer/upcoming toolchains are going to trip on that part of generated code, so we may need to be implementing workarounds for many of them before EOL of S3_1 or even S3_0.

2022-07-22 20:54 Aktualisiert von: alienvalkyrie
  • Status Update from Offen to Geschlossen
  • Lösung Update from Accepted to Gefixt
Kommentar

Reply To cazfi

we may need to be implementing workarounds for many of them before EOL of S3_1 or even S3_0.

Right, so probably even the ugly solution would've been worth it (not that this ended up being relevant, since the ugly solution wasn't necessary).

Bearbeiten

Please login to add comment to this ticket » Anmelden