On Sun, Nov 17, 2024 at 05:45:12PM +0100, Kevin Kofler via devel wrote:
> Zbigniew Jędrzejewski-Szmek wrote:
> > Heh, that's a cool idea. But that's not how standards work.
> > You cannot just insert things at random points in low-level config
> > files or protols. How do you think this would work?
> > You insert "$tuned_params", I insert "{tuned_params}", and GNU people
> > insert "@TUNED_PARAMS@", all because the spec didn't say that's
> > forbidden?
>
> Unfortunately, that is exactly how standards work in the real world. Pretty
> much any standardized language has dialects with incompatible extensions.
> Sometimes even explicitly ignoring a rule in the standard that forbids an
> extension at this place (and if you are lucky, the implementation providing
> an off-by-default flag to actually enforce that rule, flag which may or may
> not work reliably). Expecting any particular implementation to actually
> strictly conform to a standard and to always flag all non-strictly-
> conforming input is not a realistic expectation.
Yes and no. I don't argue that extensions happen and that they even
are useful. The problem here is that the extension happened in a way
that was strictly incompatible with the existing implementations (and
to a large extent the very idea that lead to the creation of the format)
and was done on files in the location read by multiple implementations,
not some private directory.
So… taking your example, nowadays C is often used with GCC extensions.
systemd is a very heavy user of those, it won't even compile with a
compiler that doesn't have support. But the header files it installs
in /usr/include are standards-compliant. In fact we have a bunch of
tests, including compilation with '-ansi', to avoid introducing a
non-standard extension in a shared location. If we did that, we'd
effectively force anyone compiling against libsystemd to a higher
standard version. People would be understandably unhappy and it'd get
immediately reverted.
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
