On 3/31/20 4:12 PM, Anatol Pomozov wrote: > C18 is the latest stable specification of the language that is > supported by modern toolchains. > It sounds reasonable to me if pacman keeps up with the technology > stack and uses its advancements.
What advancements are used as a direct result of passing -std=c11? What generated object code does this patch *on its own*, change? > Are you saying that C18 requirement introduces limits due to > requirement of this 2 years old toolchains? Just curious what > platforms where pacman is used lacks these toolchains? The limit it introduces is "over-specifying requirements". > It is not really required to use all the spec features right away. But > having an option to use it in the future is gonna be useful. > > As of particular use case - if in the future we decide to speed-up the > installation with more thread-level parallelism (e.g. checking > signatures/unpacking/... on multiple CPUs) then better C11 > mutlithreadding support is very useful. If we need it in the future, we can add it in the future. Am I missing something? If I add a new pacman feature that relies on libfoo.so, I add a dependency on libfoo.so -- but does that mean I submit a patch the year before, to "pass -lfoo when building pacman, to make the libfoo library an option since it will be useful in the future"? No, I submit a patch that introduces the use of libfoo functions, and in the same patch, I add -lfoo to the build flags. So, it seems reasonable to wait until we want to add c11 features to pacman, and then submit a patch with the new features, and bump the minimum-required-language-version argument at the same time. -- Eli Schwartz Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
