Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.std.c Subject: Re: Making more of the C standard library mandatory for freestanding implementations Date: Fri, 08 May 2020 12:03:26 -0700 Organization: A noiseless patient Spider Lines: 92 Message-ID: <867dxmz1tt.fsf@linuxsc.com> References: <86k11nzy2f.fsf@linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="b5e8c1925c1f5a62ad5a60468d6da6c6"; logging-data="31890"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/WA8ZHQGN3VnRLeou/xypEFTJcEaJJdL8=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:ruuKZMTJKn69vkkA3vNmxQ5xRUc= sha1:ZHeixiztihZwamrc/FB9BtDn01w= Xref: csiph.com comp.std.c:6112 Philipp Klaus Krause writes: > Am 07.05.20 um 15:14 schrieb Tim Rentsch: > >> Freestanding implementations may provide whatever additional >> library facilities they choose, but the required set should >> be kept where it is, at an absolute minimum. > > Why? I would turn that question around and ask why should the minimum be raised? Your written proposal doesn't offer even any good arguments, let alone any compelling or convincing ones. > By the same argument you could make support for int or anything else > optional for freestanding implemnentations. That's wrong. The case for int is not at all the same argument. * Every program uses int. Not every program uses any functions. * Supporting int has no runtime footprint costs even on pretty tiny processors. Functions in often do. * Support for int on freestanding implementations is already in the Standard. The default position is always in favor of the status quo. Removing support for int would need at the very least a compelling argument to do so; leaving it in needs no argument at all. This situation is exactly reversed for the proposal. > Stuff that cannot be implemented easily on certain hardware should > surely be optional (or even better, the standard should try to avoid > introducing features in a way that make them hard or inefficient to > implement on certain types of hardware). Personally I think there are reasons to consider lowering the requirements on freestanding implementations for integer types wider than int, and perhaps make floating point optional entirely. But that is another conversation. Your argument is basically "if it can be done then it should be done." First off the "can be done" part has not been established. Second, even if it were, it's a bogus argument. A lot of programs (that would run on very small processors and thus on freestanding implementations) don't need any functions from . A minimal standard should be exactly that: minimal. The idea that should be mandatory everywhere is part of a broader trend that C should be made more uniform by insisting that implementations be more homogenous. A justification sometimes offered for this is so programs will be "more portable" (and indeed this aspect is mentioned in your proposal). That reasoning is fundamentally misguided. C isn't like Ada, where its use can be mandated, and certification is necessary. If the bar is raised, the "offending implementations" won't change, they will just be left as non-conforming. That effect will /reduce/ the incentive to comply with the rest of the Standard, not raise it. Fundamental truth: programs are not made "more portable" by limiting the set of platforms (HW+SW) that have conforming implementations. Applications don't have to support every possible conforming implementation; they are perfectly free to rule out any that don't give them what they need (ideally with preprocessor conditionals or static assertions, but that is a separate topic). But thinking a program is "more portable" by virtue of having ruled out all implementations where it wouldn't work is like an ostrich sticking its head in the sand. > But I haven't yet seen a good reason to keep stuff like memcpy() > that can easily be implemented on any hardware on which C can be > implemented at all, optional. First, that isn't what you're proposing. The proposal says , not memcpy(). Second, the use of "easily" is too glib. You haven't made any effort, at least not that I can see, to quantify the cost on implementations to comply with the suggested additions. (Also, the proposal is a bit vague about exactly what /is/ being suggested, and this deficiency needs to be corrected before the proposal should receive any further serious attention.) Third, there is no mention of any possible alternatives that might satisfy the needs. Come to think of it, there wasn't any statement of what the needs are - the proposal looks like a solution in search of a problem. Fourth, and perhaps most important, you don't seem to grasp that since you are the one proposing a change, it's up to you to find reasoning that convinces others that it _should_ be done, not up to others to find reasons that convince you that it _shouldn't_ be done. Your proposal, your burden of proof.