Hi Jan, > But why not simply moving the limit check before using cfgpart[count]? Then > the tmp variable would be unneeded.
that was my first attempt as well, but during testing I realized it breaks the counting mechanism. The key observation is: - probe_config_file needs write-access to a valid CONFIG_PART struct - counter is only increased if probe_config_file was successful Thus, in order to detect N config partitions, probe_config_file needs to succeed N times and therefore requires N CONFIG_PART structs. Since the code wants to detect the situation where we have ENV_NUM_CONFIG_PARTS + 1 partitions, and cfgpart is an array with ENV_NUM_CONFIG_PARTS elements, this won't work. Hence the introduction of the tmp variable. I agree that it's not that nice. I guess we could also rewrite the probe_config_file method signature so that it no longer requires the struct, but only some individual fields (although this could end up in a similar situation). -- Michael Adler Siemens AG T RDA IOT SES-DE Otto-Hahn-Ring 6 81739 München, Deutschland Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim Hagemann Snabe; Vorstand: Roland Busch, Vorsitzender; Klaus Helmrich, Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin-Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322 -- You received this message because you are subscribed to the Google Groups "EFI Boot Guard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/20211203090849.jv67dwcif3dzzmlh%40kratos.
