On Wed, Nov 06, 2024 at 01:50:28PM +0100, Jaroslav Škarvada wrote: > On Wed, Nov 6, 2024 at 12:59 PM Kilian Hanich via devel > <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > Am 06.11.24 um 11:32 schrieb Zbigniew Jędrzejewski-Szmek: > > >> That's not how standards work. It's behaviour undefined by the > > >> standard, i.e. undefined behaviour. If it isn't forbidden, or strictly > > >> defined, it's still standard compliant. > > > I think we'll have to agree to disagree. If it's "undefined behaviour" > > > than it's not "standard compliant". > > > > I am just going to leave this here, so *all* of you are on the same page: > > > > A standard (doesn't matter which) can define certain things, outlaw > > certain things or leave things undefined. Nah. We're not talking about some abstract standard. We're talking about the BLS which says that it's a basic key=value list. It even has bunch of examples with file names. The text wasn't very explicit about how the file names are formatted, because it was considered obvious and unambiguous. It only says that the paths are relative to the root of the partition. The whole standard has not concept of variables. When this is extended with additional syntax, for example variable expansion, the new form in not compatible. It certainly will not be understood by any of the existing parsers which were written for the spec. The problem was always that such an extension was done under the original name. If grub were to define its own format in its own locations in the file system, there would be no problem. Unfortunately the same name and the same directories were used, and we're still dealing with the resulting confusion. > It isn't undefined behaviour, the behaviour is cleanly defined in the > grub documentation. It's undefined in the BLS. Right. So this is not the BLS. > Although BLS wasn't our primary goal (our goal is a working > product), I am ready to do my best to improve things according to > standards, BLS including Great, thank you. Zbyszek -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
