1. Forum
  2. Usenet
  3. COMP.STD.C

  • Remove all standard library functions that depend on intmax_t

    From Philipp Klaus Krause@21:1/5 to All on Thu May 7 12:58:10 2020
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Keith Thompson@21:1/5 to Philipp Klaus Krause on Thu May 7 16:54:23 2020
    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 */

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Philipp Klaus Krause@21:1/5 to All on Fri May 8 21:42:56 2020
    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)"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)