Hi.
(Sorry for the very late reply) Le lundi 7 février 2022, 21:22:20 CET Simon Glass a écrit : > Hi Francis, > > On Sun, 6 Feb 2022 at 11:23, Francis Laniel > > <francis.lan...@amarulasolutions.com> wrote: > > Le mercredi 12 janvier 2022, 21:03:37 CET Simon Glass a écrit : > > > Hi Francis, > > > > > > On Fri, 31 Dec 2021 at 09:14, Francis Laniel > > > > > > <francis.lan...@amarulasolutions.com> wrote: > > > > This commit modifies the expected result for hush 2021. > > > > Indeed, there were bugs in actual U-Boot hush which were fixed in > > > > upstream > > > > Busybox. > > > > As hush 2021 is based on upstream Busybox, these bugs no longer exist. > > > > > > > > Signed-off-by: Francis Laniel <francis.lan...@amarulasolutions.com> > > > > --- > > > > > > > > test/hush/dollar.c | 51 > > > > ++++++++++++++++++++++++++++++++++++++++++++++ > > > > 1 file changed, 51 insertions(+) > > > > > > Reviewed-by: Simon Glass <s...@chromium.org> > > > > > > Can you avoid the preprocessor macros? > > > > > > Also, for testing we really want to be able to run both sets of tests > > > in sandbox, so the parser needs to be run-time selectable. > > > > To be sure, you would like to have a global variable named, for example, > > parser which value could be: > > * parser = "old", for old hush parser > > * parser = "2021", for "new" hush parser > > Is my understanding correct? > > Yes although an int would be better than a string, perhaps controlled > by a flag in global_data and a 'cli' subcommand to change the > setting. If I understand correctly, that would mean to compile both the old and new parser? Hence, I think I will need to rename some functions in the new parser to avoid problems at this level. > Regards, > Simon