Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c > #6094 > unrolled thread

Remove all standard library functions that depend on intmax_t

Back to article view | Back to comp.std.c

Contents

  Remove all standard library functions that depend on intmax_t Philipp Klaus Krause <pkk@spth.de> - 2020-05-07 12:58 +0200
    Re: Remove all standard library functions that depend on intmax_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-07 16:54 -0700
      Re: Remove all standard library functions that depend on intmax_t Philipp Klaus Krause <pkk@spth.de> - 2020-05-08 21:42 +0200

#6094 — Remove all standard library functions that depend on intmax_t

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.

I just wrote a first draft of a proposal that removes all functions in
the standard library that depend on intmax_t, and alos the j specifier
from the printf and scanf family:

http://www.colecovision.eu/stuff/proposal-no-ufromfpx.html

I did not touch the intmax_t type itself.

Do you see any problem with the proposal?

[toc] | [next] | [standalone]

#6105

Philipp Klaus Krause <pkk@spth.de> 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 */

[toc] | [prev] | [next] | [standalone]

#6116

Am 08.05.20 um 01:54 schrieb Keith Thompson:
> 
> 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.
> 
> [...]
> 

See N2516, "Draft April 2020 meeting minutes".

First there was a "Straw Poll: Do we want to make any changes to
intmax_t? 12-5-0 (passes)".

Then all proposals for changes to or replacements for intmax_t failed in
the individual straw polls.

Then there was a "Straw Poll: Should the committee pursue something
along the lines of deprecating intmax_t as a type? 7-3-5 (passes)"

[toc] | [prev] | [standalone]

Back to top | Article view | comp.std.c

csiph-web