Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.std.c Subject: Re: Remove all standard library functions that depend on intmax_t Date: Thu, 07 May 2020 16:54:23 -0700 Organization: None to speak of Lines: 24 Message-ID: <87r1vvti6o.fsf@nosuchdomain.example.com> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="d0e163fa66eebc70bf6f0563ec624057"; logging-data="671"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19yWul74lr41Gr0UNwRIC2e" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cancel-Lock: sha1:Ijgk0lE20UIfBMLOORrVrbYuvow= sha1:fC7i884YVQ7LHhaodOXHmev3iOE= Xref: csiph.com comp.std.c:6105 Philipp Klaus Krause writes: > At the spring WG14 meeting, there were various proposals on how to deal > with the intmax_t problem (intmax_t being baked into ABIs makes it hard > to grow it). One would have been to remove all use of intmax_t in the > standard libary to get it out of the ABI. But in the end, a much more > radical decision was made: Remove intmax_t without replacement. Do you have a reference to this? Did they really decide to remove intmax_t altogether? http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2498.pdf (dated 2020-02-29) is a proposal to keep (u)intmax_t but deprecate library functions that depend on them. Removing (u)intmax_t altogether would break existing code. See http://www.open-std.org/jtc1/sc22/wg14/www/docs/PreFreiburg2020.htm for some other similar proposals. [...] -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */