Path: csiph.com!weretis.net!feeder8.news.weretis.net!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Why does C allow structs to have a tag? Date: Fri, 01 Oct 2021 13:44:35 -0700 Organization: A noiseless patient Spider Lines: 47 Message-ID: <86czootqz0.fsf@linuxsc.com> References: <87czqnlp2m.fsf@bsb.me.uk> <2c0cb99f-2d5f-4149-8b03-d96ecc3d6543n@googlegroups.com> <1f79b2e5-0e07-488f-a529-c00f7d6e046fn@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="1f711ea4a721fffeb2fc6a5c47f1cdc3"; logging-data="11894"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18VF9u7VJfytckXL+vm/eAcsIKxgO8kzJs=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:QYqPRk08kaClNwu54KTp+6Y7rtQ= sha1:6qMbyrkM/eHFYs/fxMZ/BRhJ33g= Xref: csiph.com comp.lang.c:162916 Michael S writes: > On Wednesday, August 11, 2021 at 4:55:41 PM UTC+3, Scott Lurndal wrote: > >> Michael S writes: >> >>> On Wednesday, August 11, 2021 at 11:34:16 AM UTC+3, >>> anti...@math.uni.wroc.pl wrote: >>> [...] >>> strcat() should have been deprecated in 1989 with replacement that >>> returns something potentially useful, e.g. pointer to >>> termination character of result string or length of result string. >>> Or return nothing, which still would be an improvement. >>> >>> But committees have their own logic. >> >> Having been a member of those committees for a decade, I'll point >> out that deprecating or changing the semantics of strcat > > For me, deprecation does not mean *immediate* removal. For me, it > mean that we threaten to remove a function in 15 years time and > are actually removing it after 30 years. Or never. The ISO C standard normally uses the term "obsolescent" to indicate a language or library feature that may be removed at some indeterminate point in the future. If ever, and not necessarily - some language or library features have been termed "obsolescent" in earlier versions of the C standard but restored to non-obsolescent status in later versions. The ISO C standard normally uses the term "deprecated" to indicate a language or library feature that is expected to be removed in some subsequent version of the C standard. There is a good chance that removal happens soon (e.g., in the next release) but there is no guarantee of that. > But in the mean time conforming compilers issue annoying > diagnostics. The ISO C standard does not require diagnostics either for obsolescent features or deprecated features. I think it's common for implemenations to issue diagnostics for deprecated features but that is completely up to the implementation. And of course an implementation is free to issue diagnostics for anything it wants to, as long as it accepts all strictly conforming programs (and using obsolescent or deprecated features doesn't violate that condition, IIANM).