Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #79727 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2021-05-24 20:46 -0500 |
| Last post | 2021-06-01 17:35 -0700 |
| Articles | 20 on this page of 112 — 21 participants |
Back to article view | Back to comp.lang.c++
recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-24 20:46 -0500
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-24 20:50 -0500
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-24 20:52 -0500
Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-25 07:47 +0300
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-25 12:20 -0500
Re: recovering from std::bad_alloc in std::string reserve Christian Gollwitzer <auriocus@gmx.de> - 2021-05-26 08:36 +0200
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-26 13:28 -0500
Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 12:56 +0200
Re: recovering from std::bad_alloc in std::string reserve scott@slp53.sl.home (Scott Lurndal) - 2021-05-25 14:55 +0000
Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-25 18:42 +0300
Re: recovering from std::bad_alloc in std::string reserve MrSpook_Ann1u@d0v_5eh1bqgd.com - 2021-05-25 16:10 +0000
Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 18:23 +0200
Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-25 19:57 +0300
Re: recovering from std::bad_alloc in std::string reserve MrSpook_ddZgr4t4@okc9_pd48oig5.info - 2021-05-26 07:15 +0000
Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-26 09:22 +0200
Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-26 10:54 +0300
Re: recovering from std::bad_alloc in std::string reserve MrSpook_dw5lvA4g@kak0_42x.edu - 2021-05-26 08:29 +0000
Re: recovering from std::bad_alloc in std::string reserve Nikolaj Lazic <nlazicBEZ_OVOGA@mudrac.ffzg.hr> - 2021-05-25 16:21 +0000
Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-25 20:04 +0300
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-25 12:46 -0500
Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-25 20:58 +0300
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-25 13:48 -0500
Re: recovering from std::bad_alloc in std::string reserve Nikolaj Lazic <nlazicBEZ_OVOGA@mudrac.ffzg.hr> - 2021-05-25 18:23 +0000
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-25 13:49 -0500
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-26 21:07 -0500
Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 18:23 +0200
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-24 22:33 -0500
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-24 22:35 -0500
Re: recovering from std::bad_alloc in std::string reserve Juha Nieminen <nospam@thanks.invalid> - 2021-05-25 05:16 +0000
Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 13:00 +0200
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-25 12:49 -0500
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-27 14:08 -0500
Re: recovering from std::bad_alloc in std::string reserve scott@slp53.sl.home (Scott Lurndal) - 2021-05-27 21:59 +0000
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-27 15:33 -0700
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-27 15:58 -0700
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-27 18:17 -0500
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-27 16:58 -0700
Re: recovering from std::bad_alloc in std::string reserve Öö Tiib <ootiib@hot.ee> - 2021-05-27 18:36 -0700
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-27 21:38 -0500
Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-28 08:53 +0300
Re: recovering from std::bad_alloc in std::string reserve Bo Persson <bo@bo-persson.se> - 2021-05-28 09:47 +0200
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-27 19:54 -0700
Re: recovering from std::bad_alloc in std::string reserve Öö Tiib <ootiib@hot.ee> - 2021-05-27 21:02 -0700
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-28 12:09 -0700
Re: recovering from std::bad_alloc in std::string reserve scott@slp53.sl.home (Scott Lurndal) - 2021-05-28 20:26 +0000
Re: recovering from std::bad_alloc in std::string reserve Öö Tiib <ootiib@hot.ee> - 2021-05-28 17:10 -0700
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-05-29 11:47 +0200
Re: recovering from std::bad_alloc in std::string reserve "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-05-30 15:15 -0700
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-05-31 08:33 +0200
Re: recovering from std::bad_alloc in std::string reserve "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-05-31 08:21 -0700
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-05-31 18:13 +0200
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-31 14:43 -0700
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-31 14:44 -0700
Re: recovering from std::bad_alloc in std::string reserve "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-05-31 15:20 -0700
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-01 11:17 -0700
Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-01 20:25 +0200
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-01 16:55 -0700
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-02 09:06 +0200
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-05 17:50 -0700
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-06 11:10 +0200
Re: recovering from std::bad_alloc in std::string reserve Öö Tiib <ootiib@hot.ee> - 2021-06-06 04:07 -0700
Re: recovering from std::bad_alloc in std::string reserve Richard Damon <Richard@Damon-Family.org> - 2021-06-06 07:49 -0400
Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-01 20:21 +0200
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-02 09:29 +0200
Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-02 18:43 +0200
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-02 23:32 +0200
Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-03 00:49 +0200
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-03 09:08 +0200
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-03 10:53 +0200
Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-03 16:20 +0200
Re: recovering from std::bad_alloc in std::string reserve James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-03 11:20 -0400
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-03 19:04 +0200
Re: recovering from std::bad_alloc in std::string reserve scott@slp53.sl.home (Scott Lurndal) - 2021-06-03 22:24 +0000
Re: recovering from std::bad_alloc in std::string reserve Öö Tiib <ootiib@hot.ee> - 2021-06-03 16:27 -0700
Re: recovering from std::bad_alloc in std::string reserve scott@slp53.sl.home (Scott Lurndal) - 2021-06-04 00:36 +0000
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-04 08:46 +0200
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-05 22:02 -0700
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-06 11:17 +0200
Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-06 18:39 +0200
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 16:33 -0700
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-07 08:41 +0200
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-06 17:46 +0200
Re: recovering from std::bad_alloc in std::string reserve MrSpook_Qfmtjdmi@nc6.com - 2021-06-06 14:11 +0000
Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-03 16:43 +0200
Re: recovering from std::bad_alloc in std::string reserve Manfred <noname@add.invalid> - 2021-06-01 18:00 +0200
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-01 19:15 +0200
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-01 15:55 +0200
Re: recovering from std::bad_alloc in std::string reserve Bo Persson <bo@bo-persson.se> - 2021-06-01 13:59 +0200
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-06-01 13:26 -0500
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-01 08:29 +0200
Re: recovering from std::bad_alloc in std::string reserve Bo Persson <bo@bo-persson.se> - 2021-06-01 14:05 +0200
Re: recovering from std::bad_alloc in std::string reserve David Brown <david.brown@hesbynett.no> - 2021-06-01 15:58 +0200
Re: recovering from std::bad_alloc in std::string reserve James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-01 11:33 -0400
Re: recovering from std::bad_alloc in std::string reserve Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-01 10:52 -0700
Re: recovering from std::bad_alloc in std::string reserve James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-05-27 23:16 -0400
Re: recovering from std::bad_alloc in std::string reserve scott@slp53.sl.home (Scott Lurndal) - 2021-05-28 14:34 +0000
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-27 18:19 -0500
Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-28 03:47 +0200
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-27 17:45 -0500
Re: recovering from std::bad_alloc in std::string reserve scott@slp53.sl.home (Scott Lurndal) - 2021-05-28 14:38 +0000
Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-28 16:44 +0200
Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-28 16:42 +0200
Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-28 18:22 +0300
Re: recovering from std::bad_alloc in std::string reserve Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-28 08:47 +0300
Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-26 06:16 +0200
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-26 13:30 -0500
Re: recovering from std::bad_alloc in std::string reserve Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-26 20:37 +0200
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-26 14:09 -0500
Re: recovering from std::bad_alloc in std::string reserve "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-05-26 18:33 +0200
Re: recovering from std::bad_alloc in std::string reserve Lynn McGuire <lynnmcguire5@gmail.com> - 2021-05-26 13:32 -0500
Re: recovering from std::bad_alloc in std::string reserve Christian Gollwitzer <auriocus@gmx.de> - 2021-05-27 07:50 +0200
Re: recovering from std::bad_alloc in std::string reserve "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-06-01 17:35 -0700
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-07 08:41 +0200 |
| Message-ID | <s9kf24$m6p$1@dont-email.me> |
| In reply to | #80204 |
On 07/06/2021 01:33, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 06/06/2021 07:02, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>>> On 04/06/2021 02:36, Scott Lurndal wrote: >>> [...] >>>>> Perhaps, but gcc generally documents all the functions that will >>>>> be inlined in their texinfo documentation, and div is not included >>>>> in the list of math functions that automatically get builtin status >>>>> at least in GCC 4.8. Since they're up to GCC11 now, they may have >>>>> added it to the list. >>>> >>>> It has not (because of the weakly specified "div_t" struct that is >>>> determined by the library implementation and not the standards or the >>>> compiler). >>>> >>>> <https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html> >>> >>> This could be done if a future C standard specified the representation >>> of type div_t (as it does for complex types). >> >> One of the suggested ways for handling this situation for gcc is, in >> fact, to use a complex type as a container for the div_t results. It >> would use the gcc extension of complex integer types (Gaussian integers, >> I suppose), precisely because it is a suitable pair of numbers whose >> structure is known to the compiler. This is just one of these odd >> things in compilers that seems simple from the outside, but has subtle >> complications in practice. > > Sure, but the type div_t is still defined in the <stdlib.h> or <cstdlib> > header, and gcc has to work with arbitrary library implementations. I must admit I did not pay much attention to the details of the gcc developers' comments there. It is not something I know a lot about, nor something that affects me directly (I use the operators) - it is just something that I think is interesting and that might be important to others. I'm cc'ed on a bug in the gcc bugzilla for it, so if there is more progress, I can report back. > > The C standard's requirements for the representation of complex types: > > Each complex type has the same representation and alignment > requirements as an array type containing exactly two elements of the > corresponding real type; the first element is equal to the real > part, and the second element to the imaginary part, of the complex > number. > > could easily be reworked to specify the representation of div_t > (and ldiv_t, and lldvi_t, and intmaxdiv_t). I strongly suspect > that all existing implementations already define the *div_t types > consistently, with quot at offset 0 and rem following it. If the > layout were specified, gcc could optimize calls to the *div() > functions (assuming it knows that the library that will be used > is conforming). > Certainly that would be the most convenient solution, and I can't see how adding that to the standard could cause trouble for existing code.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-06 17:46 +0200 |
| Message-ID | <s9iqk4$9q8$1@dont-email.me> |
| In reply to | #80177 |
On 06/06/2021 16:11, MrSpook_Qfmtjdmi@nc6.com wrote: > On Sat, 05 Jun 2021 22:02:22 -0700 > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> On 04/06/2021 02:36, Scott Lurndal wrote: >> [...] >>>> Perhaps, but gcc generally documents all the functions that will >>>> be inlined in their texinfo documentation, and div is not included >>>> in the list of math functions that automatically get builtin status >>>> at least in GCC 4.8. Since they're up to GCC11 now, they may have >>>> added it to the list. >>> >>> It has not (because of the weakly specified "div_t" struct that is >>> determined by the library implementation and not the standards or the >>> compiler). >>> >>> <https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html> >> >> This could be done if a future C standard specified the representation >> of type div_t (as it does for complex types). > > I'd be surprised if there are any future C standards. The next version after C17 is likely to be C21 or C22. (It is currently known as C2x.) You can get a draft here: <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf> There aren't any big changes so far, but some nice tidying up of obsolescent features (K&R function declarations are finally gone, as are signed integers that are not two's complement). And there are plenty of proposals being considered for future standards. > After all, whats the > point? There can't be many C programmers left that can't also program in C++ > and if you need more than C can provide, just use C++ unless its a very limited > embedded system in which case probably even the version of C it uses is limited > anyway. Also the days of C having a performance advantage are pretty much gone. > Certainly there is little point in adding a lot to the C language - the language's stability and backwards compatibility are its main benefit. But small improvements make sense, as do corrections to the standard, and it could be useful to standardise some of the common extensions to C or to import a few things from C++. > One think I'd have liked in C in the past is some form of lambda syntax and > while both clang and gcc created their own kinda, sorta versions as code blocks > and nested functions respectively they're unfortunately incompatible. Shame the > teams couldn't have got together and come up with a single solution - they must > have some cross pollination and don't work in silos unaware of whats going on > elsewhere. > >
[toc] | [prev] | [next] | [standalone]
| From | MrSpook_Qfmtjdmi@nc6.com |
|---|---|
| Date | 2021-06-06 14:11 +0000 |
| Message-ID | <s9il26$1tl2$1@gioia.aioe.org> |
| In reply to | #80177 |
On Sat, 05 Jun 2021 22:02:22 -0700 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >David Brown <david.brown@hesbynett.no> writes: >> On 04/06/2021 02:36, Scott Lurndal wrote: >[...] >>> Perhaps, but gcc generally documents all the functions that will >>> be inlined in their texinfo documentation, and div is not included >>> in the list of math functions that automatically get builtin status >>> at least in GCC 4.8. Since they're up to GCC11 now, they may have >>> added it to the list. >> >> It has not (because of the weakly specified "div_t" struct that is >> determined by the library implementation and not the standards or the >> compiler). >> >> <https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html> > >This could be done if a future C standard specified the representation >of type div_t (as it does for complex types). I'd be surprised if there are any future C standards. After all, whats the point? There can't be many C programmers left that can't also program in C++ and if you need more than C can provide, just use C++ unless its a very limited embedded system in which case probably even the version of C it uses is limited anyway. Also the days of C having a performance advantage are pretty much gone. One think I'd have liked in C in the past is some form of lambda syntax and while both clang and gcc created their own kinda, sorta versions as code blocks and nested functions respectively they're unfortunately incompatible. Shame the teams couldn't have got together and come up with a single solution - they must have some cross pollination and don't work in silos unaware of whats going on elsewhere.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2021-06-03 16:43 +0200 |
| Message-ID | <s9apr3$1ai0$1@gioia.aioe.org> |
| In reply to | #80116 |
On 6/2/2021 11:32 PM, David Brown wrote: > On 02/06/2021 18:43, Manfred wrote: >> On 6/2/2021 9:29 AM, David Brown wrote: >>> On 01/06/2021 20:21, Manfred wrote: >>>> On 6/1/2021 7:15 PM, David Brown wrote: >> [...] >>>>> >>>>> The situation we have now is that on a compiler like gcc you can get >>>>> 128-bit division using __int128, but /not/ using intmax_t. It is a >>>>> useless type. >>>>> >>>> >>>> The way I see it this is a problem with gcc, not with the standard. >>>> Unless the committee managed to produce some wording that is too >>>> problematic for __int128 to fit as extended integer type. >>> >>> Keith has given some replies here. >>> >>> There is nothing in the standards that would have prevented gcc making >>> __int128 as an extended integer type when C99 was introduced. The >>> problem is that the definition of intmax_t makes it extremely difficult >>> to /change/ the type, and therefore to /introduce/ a new larger extended >>> integer type at a later date. Once the ABI for a platform has been >>> decided, intmax_t is fixed and no larger integer types can be introduced >>> without change and disruption that is well out of proportion for the >>> gains. >>> >> >> Technically, this is still a problem of the implementation, not of the >> standard. Granted, implementations and the standard have a long history >> of going along together, but still they are different things and they >> work at different levels. >> I believe you and Keith (his link is indeed instructive) when you say >> that there are ABI problems with intmax_t, but I am not convinced that >> they are absolutely objective - I may think there is some weight of the >> legacy of ABI definitions as they have been structured for decades. > > Legacy and ABI definitions are definitely the issues here, and > technically these are part of the implementation, rather than the > standard. The way the standard defines intmax_t makes it very > impractical (but not impossible) for implementations to provide larger > integer types. I see that as a problem or limitation in the standard, > rather than an implementation issue. > >> After all, in C passing arguments of varying type is not a new issue - >> structs have been part of the ABI since the beginning of time. >> > > Yes, but structs (and arrays) are defined in terms of existing scaler > types. ABI's generally do not specify how to pass larger integer types > - it is not covered by the specification for a struct comprising of two > smaller types. > As far as I know ABI's do specify how to pass structs (arrays in C are a bit different in that they are passed by reference unlike all other types). The point is that in C there is some provision to pass arguments of arbitrary size, both at the level of the standard and of actual implementations. The idea of having a scalar type of arbitrary size is problematic, but it is also an opportunity, in my opinion. In fact one of the few architectural changes in the last couple of decades is the increase of word size. So it's not unreasonable that looking in perspective the committee wanted to introduce some support for 'large' scalars - integers being the obvious choice. We have seen the demand for such types grow from 8 to 128 bits, processor words grow from 8 to 64 bits, and given the increasing demand for e.g. cryptography, with the vital role of secure communications already today, it makes some sense to envision that these numbers could keep growing sooner or later.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2021-06-01 18:00 +0200 |
| Message-ID | <s95lin$16jr$1@gioia.aioe.org> |
| In reply to | #80030 |
On 6/1/2021 3:55 PM, David Brown wrote: > On 01/06/2021 13:59, Bo Persson wrote: >> On 2021-06-01 at 00:20, daniel...@gmail.com wrote: >>> On Monday, May 31, 2021 at 5:43:23 PM UTC-4, Keith Thompson wrote: >>>> David Brown <david...@hesbynett.no> writes: >>>>> On 31/05/2021 00:15, daniel...@gmail.com wrote: >>>>>> On Saturday, May 29, 2021 at 5:47:50 AM UTC-4, David Brown wrote: >>>>>>> The definition of intmax_t is a problem - it is a limitation for >>>>>>> integer >>>>>>> types in C and C++. Hopefully eventually deprecate intmax_t. >>>>>> >>>>>> One proposal is to make intmax_t mean int64_t, and leave it at that. >>>>>> Have no requirement that integer types can't be larger. No more ABI >>>>>> problem. >>>>> >>>>> It might make more sense to tie it to "long long int" rather than >>>>> "int64_t", but someone would first have to check if it affected any >>>>> real >>>>> implementations before making such a change. But yes, that might be a >>>>> way out and a way forward. >>>> [...] >>>> >>>> That would allow intmax_t to be 128 bits on implementations with >>>> 128-bit long long (are there any?), which seems like a good idea. >>>> >>>> I think the point of both these proposals is purely for backward >>>> compatibility, avoiding breaking code that already uses [u]intmax_t. >>>> Both of them destroy the point of intmax_t, providing a type that's >>>> guaranteed to be the longest integer type. Should intmax_t be >>>> deprecated? >>>> >>> Yes. "Give me the biggest integer type there is" is not a reasonable >>> thing to ask for, in any code that is intended to be portable across >>> platforms >>> or over time on the same platform. You may as well have intwhatever_t. >>> >> >> The problem is that we in general don't know what "whatever" is. At the >> time when intmax_t was introduced, at least in C there were >> implementations with 36 bit ints and 72-bit longs. So just using int64_t >> would not be portable. >> > > Have there ever been C99 compilers for 36-bit int machines? Were there > even conforming C90 compilers? > > AFAIK (and I fully admit my knowledge may be lacking), the only systems > that made it past the 1980's which did not have two's complement signed > integers with 8-bit bytes and power-of-two sized integer types are some > DSPs and other niche embedded devices (for which no one would use an > integer type without knowing /exactly/ how big it is), and > Burroughs/Unisys systems for legacy compatibility. > > My suggestion would be to lock intmax_t to "long long", which would keep > compatibility here (including for systems that have 128-bit long long, > if there are any other than a hypothetical RISC-V version). > > > I think this would be problematic as well, or at least useless and confusing. The idea for intmax_t is to give a standard name to the widest integer type that is available, which is by definition implementation defined. Having intmax_t an alias for "long long" would change its meaning to the widest /standard/ integer type defined by the standard itself - a useless repetition (we have "long long" for that), and confusing too, given its change in meaning. As far as I understand the purpose for intmax_t is to allow for (sort of) 'standard' prototypes of functions like imaxabs, imaxdiv, strtoimax, etc that are supposed to operate on larger integer types - these are the only functions that take this kind of arguments. The confusing part is that all of these facilities are implementation dependent, so even if they are part of the standard they are /not/ portable, meaning that the programmer is supposed (the way I see it) to use them under the guard of appropriate preprocessor directives. The use for them is to allow the programmer to use some optimized routines for larger types, if available. For example, in case operations like ldiv are needed on 128 bit integers, then IF the implementation supports 128 bit intmax_t then imaxdiv can be a better choice rather than implementing your own routine - note that /IF/ is the keyword here, that should map directly to appropriate #if directives. It's most probably somewhat a niche field of use (possibly growing due to the diffuse demand for cryptography), or meant for applications that are supposed to be run on hardware that is known to support the appropriate types, so that the #if directives can be as simple as denying compilation for implementations that don't have a wide enough intmax_t. My 2c.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-01 19:15 +0200 |
| Message-ID | <s95pus$10s$1@dont-email.me> |
| In reply to | #80047 |
On 01/06/2021 18:00, Manfred wrote: > On 6/1/2021 3:55 PM, David Brown wrote: >> On 01/06/2021 13:59, Bo Persson wrote: >>> On 2021-06-01 at 00:20, daniel...@gmail.com wrote: >>>> On Monday, May 31, 2021 at 5:43:23 PM UTC-4, Keith Thompson wrote: >>>>> David Brown <david...@hesbynett.no> writes: >>>>>> On 31/05/2021 00:15, daniel...@gmail.com wrote: >>>>>>> On Saturday, May 29, 2021 at 5:47:50 AM UTC-4, David Brown wrote: >>>>>>>> The definition of intmax_t is a problem - it is a limitation for >>>>>>>> integer >>>>>>>> types in C and C++. Hopefully eventually deprecate intmax_t. >>>>>>> >>>>>>> One proposal is to make intmax_t mean int64_t, and leave it at that. >>>>>>> Have no requirement that integer types can't be larger. No more ABI >>>>>>> problem. >>>>>> >>>>>> It might make more sense to tie it to "long long int" rather than >>>>>> "int64_t", but someone would first have to check if it affected any >>>>>> real >>>>>> implementations before making such a change. But yes, that might be a >>>>>> way out and a way forward. >>>>> [...] >>>>> >>>>> That would allow intmax_t to be 128 bits on implementations with >>>>> 128-bit long long (are there any?), which seems like a good idea. >>>>> >>>>> I think the point of both these proposals is purely for backward >>>>> compatibility, avoiding breaking code that already uses [u]intmax_t. >>>>> Both of them destroy the point of intmax_t, providing a type that's >>>>> guaranteed to be the longest integer type. Should intmax_t be >>>>> deprecated? >>>>> >>>> Yes. "Give me the biggest integer type there is" is not a reasonable >>>> thing to ask for, in any code that is intended to be portable across >>>> platforms >>>> or over time on the same platform. You may as well have intwhatever_t. >>>> >>> >>> The problem is that we in general don't know what "whatever" is. At the >>> time when intmax_t was introduced, at least in C there were >>> implementations with 36 bit ints and 72-bit longs. So just using int64_t >>> would not be portable. >>> >> >> Have there ever been C99 compilers for 36-bit int machines? Were there >> even conforming C90 compilers? >> >> AFAIK (and I fully admit my knowledge may be lacking), the only systems >> that made it past the 1980's which did not have two's complement signed >> integers with 8-bit bytes and power-of-two sized integer types are some >> DSPs and other niche embedded devices (for which no one would use an >> integer type without knowing /exactly/ how big it is), and >> Burroughs/Unisys systems for legacy compatibility. >> >> My suggestion would be to lock intmax_t to "long long", which would keep >> compatibility here (including for systems that have 128-bit long long, >> if there are any other than a hypothetical RISC-V version). >> >> >> > > I think this would be problematic as well, or at least useless and > confusing. > The idea for intmax_t is to give a standard name to the widest integer > type that is available, which is by definition implementation defined. > Having intmax_t an alias for "long long" would change its meaning to the > widest /standard/ integer type defined by the standard itself - a > useless repetition (we have "long long" for that), and confusing too, > given its change in meaning. Yes, that is all true. The point is not to find another useful purpose for intmax_t - the point is to get rid of it, marking it as deprecated, but to do so in a way that won't break existing code. I am at a loss to understand why anyone would have a use for intmax_t in the first place. When would you want an integer type whose sole characteristic is "big" ? To me, it is logical to want a type that is at least N bits, or exactly N bits. These requirements are covered by the normal "short", "int", "long" and "long long" types, or - better for my use, but not necessarily other people's - the <stdint.h> fixed size types. "intmax_t" gives you absolutely /nothing/ that "long long" does not. Given that there are, as far as we know, no implementations where intmax_t does not correspond directly to "long long", I would like to see "intmax_t" be dropped to the maximum extent allowable by backwards compatibility. > > As far as I understand the purpose for intmax_t is to allow for (sort > of) 'standard' prototypes of functions like imaxabs, imaxdiv, strtoimax, > etc that are supposed to operate on larger integer types - these are the > only functions that take this kind of arguments. > The confusing part is that all of these facilities are implementation > dependent, so even if they are part of the standard they are /not/ > portable, meaning that the programmer is supposed (the way I see it) to > use them under the guard of appropriate preprocessor directives. > > The use for them is to allow the programmer to use some optimized > routines for larger types, if available. But they don't allow that. If you are trying to make optimised routines for larger types, you need to know your sizes - you either use implementation extensions (like __int128), or fixed size types, or if you need maximal portability, you use "int_fast64_t". > > For example, in case operations like ldiv are needed on 128 bit > integers, then IF the implementation supports 128 bit intmax_t then > imaxdiv can be a better choice rather than implementing your own routine > - note that /IF/ is the keyword here, that should map directly to > appropriate #if directives. > The situation we have now is that on a compiler like gcc you can get 128-bit division using __int128, but /not/ using intmax_t. It is a useless type. > It's most probably somewhat a niche field of use (possibly growing due > to the diffuse demand for cryptography), or meant for applications that > are supposed to be run on hardware that is known to support the > appropriate types, so that the #if directives can be as simple as > denying compilation for implementations that don't have a wide enough > intmax_t. > > My 2c.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-01 15:55 +0200 |
| Message-ID | <s95e8b$a8p$1@dont-email.me> |
| In reply to | #80030 |
On 01/06/2021 13:59, Bo Persson wrote: > On 2021-06-01 at 00:20, daniel...@gmail.com wrote: >> On Monday, May 31, 2021 at 5:43:23 PM UTC-4, Keith Thompson wrote: >>> David Brown <david...@hesbynett.no> writes: >>>> On 31/05/2021 00:15, daniel...@gmail.com wrote: >>>>> On Saturday, May 29, 2021 at 5:47:50 AM UTC-4, David Brown wrote: >>>>>> The definition of intmax_t is a problem - it is a limitation for >>>>>> integer >>>>>> types in C and C++. Hopefully eventually deprecate intmax_t. >>>>> >>>>> One proposal is to make intmax_t mean int64_t, and leave it at that. >>>>> Have no requirement that integer types can't be larger. No more ABI >>>>> problem. >>>> >>>> It might make more sense to tie it to "long long int" rather than >>>> "int64_t", but someone would first have to check if it affected any >>>> real >>>> implementations before making such a change. But yes, that might be a >>>> way out and a way forward. >>> [...] >>> >>> That would allow intmax_t to be 128 bits on implementations with >>> 128-bit long long (are there any?), which seems like a good idea. >>> >>> I think the point of both these proposals is purely for backward >>> compatibility, avoiding breaking code that already uses [u]intmax_t. >>> Both of them destroy the point of intmax_t, providing a type that's >>> guaranteed to be the longest integer type. Should intmax_t be >>> deprecated? >>> >> Yes. "Give me the biggest integer type there is" is not a reasonable >> thing to ask for, in any code that is intended to be portable across >> platforms >> or over time on the same platform. You may as well have intwhatever_t. >> > > The problem is that we in general don't know what "whatever" is. At the > time when intmax_t was introduced, at least in C there were > implementations with 36 bit ints and 72-bit longs. So just using int64_t > would not be portable. > Have there ever been C99 compilers for 36-bit int machines? Were there even conforming C90 compilers? AFAIK (and I fully admit my knowledge may be lacking), the only systems that made it past the 1980's which did not have two's complement signed integers with 8-bit bytes and power-of-two sized integer types are some DSPs and other niche embedded devices (for which no one would use an integer type without knowing /exactly/ how big it is), and Burroughs/Unisys systems for legacy compatibility. My suggestion would be to lock intmax_t to "long long", which would keep compatibility here (including for systems that have 128-bit long long, if there are any other than a hypothetical RISC-V version).
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2021-06-01 13:59 +0200 |
| Message-ID | <ihmlopF4ff6U1@mid.individual.net> |
| In reply to | #80030 |
On 2021-06-01 at 00:20, daniel...@gmail.com wrote: > On Monday, May 31, 2021 at 5:43:23 PM UTC-4, Keith Thompson wrote: >> David Brown <david...@hesbynett.no> writes: >>> On 31/05/2021 00:15, daniel...@gmail.com wrote: >>>> On Saturday, May 29, 2021 at 5:47:50 AM UTC-4, David Brown wrote: >>>>> The definition of intmax_t is a problem - it is a limitation for integer >>>>> types in C and C++. Hopefully eventually deprecate intmax_t. >>>> >>>> One proposal is to make intmax_t mean int64_t, and leave it at that. >>>> Have no requirement that integer types can't be larger. No more ABI >>>> problem. >>> >>> It might make more sense to tie it to "long long int" rather than >>> "int64_t", but someone would first have to check if it affected any real >>> implementations before making such a change. But yes, that might be a >>> way out and a way forward. >> [...] >> >> That would allow intmax_t to be 128 bits on implementations with >> 128-bit long long (are there any?), which seems like a good idea. >> >> I think the point of both these proposals is purely for backward >> compatibility, avoiding breaking code that already uses [u]intmax_t. >> Both of them destroy the point of intmax_t, providing a type that's >> guaranteed to be the longest integer type. Should intmax_t be >> deprecated? >> > Yes. "Give me the biggest integer type there is" is not a reasonable > thing to ask for, in any code that is intended to be portable across platforms > or over time on the same platform. You may as well have intwhatever_t. > The problem is that we in general don't know what "whatever" is. At the time when intmax_t was introduced, at least in C there were implementations with 36 bit ints and 72-bit longs. So just using int64_t would not be portable.
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2021-06-01 13:26 -0500 |
| Message-ID | <s95u4q$sqj$2@dont-email.me> |
| In reply to | #80054 |
On 6/1/2021 6:59 AM, Bo Persson wrote: > On 2021-06-01 at 00:20, daniel...@gmail.com wrote: >> On Monday, May 31, 2021 at 5:43:23 PM UTC-4, Keith Thompson wrote: >>> David Brown <david...@hesbynett.no> writes: >>>> On 31/05/2021 00:15, daniel...@gmail.com wrote: >>>>> On Saturday, May 29, 2021 at 5:47:50 AM UTC-4, David Brown wrote: >>>>>> The definition of intmax_t is a problem - it is a limitation for >>>>>> integer >>>>>> types in C and C++. Hopefully eventually deprecate intmax_t. >>>>> >>>>> One proposal is to make intmax_t mean int64_t, and leave it at that. >>>>> Have no requirement that integer types can't be larger. No more ABI >>>>> problem. >>>> >>>> It might make more sense to tie it to "long long int" rather than >>>> "int64_t", but someone would first have to check if it affected any >>>> real >>>> implementations before making such a change. But yes, that might be a >>>> way out and a way forward. >>> [...] >>> >>> That would allow intmax_t to be 128 bits on implementations with >>> 128-bit long long (are there any?), which seems like a good idea. >>> >>> I think the point of both these proposals is purely for backward >>> compatibility, avoiding breaking code that already uses [u]intmax_t. >>> Both of them destroy the point of intmax_t, providing a type that's >>> guaranteed to be the longest integer type. Should intmax_t be >>> deprecated? >>> >> Yes. "Give me the biggest integer type there is" is not a reasonable >> thing to ask for, in any code that is intended to be portable across >> platforms >> or over time on the same platform. You may as well have intwhatever_t. >> > > The problem is that we in general don't know what "whatever" is. At the > time when intmax_t was introduced, at least in C there were > implementations with 36 bit ints and 72-bit longs. So just using int64_t > would not be portable. Don't forget the 60 bit int / 120 bit long CDC 7600 machines. The only 36 bit machine that I knew was the Univac 1108 that the IRS reputedly used until 2010 or so. Lynn
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-01 08:29 +0200 |
| Message-ID | <s94k4t$s93$1@dont-email.me> |
| In reply to | #80028 |
On 31/05/2021 23:43, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 31/05/2021 00:15, daniel...@gmail.com wrote: >>> On Saturday, May 29, 2021 at 5:47:50 AM UTC-4, David Brown wrote: >>>> The definition of intmax_t is a problem - it is a limitation for integer >>>> types in C and C++. Hopefully eventually deprecate intmax_t. >>> >>> One proposal is to make intmax_t mean int64_t, and leave it at that. >>> Have no requirement that integer types can't be larger. No more ABI >>> problem. >> >> It might make more sense to tie it to "long long int" rather than >> "int64_t", but someone would first have to check if it affected any real >> implementations before making such a change. But yes, that might be a >> way out and a way forward. > > [...] > > That would allow intmax_t to be 128 bits on implementations with > 128-bit long long (are there any?), which seems like a good idea. > > I think the point of both these proposals is purely for backward > compatibility, avoiding breaking code that already uses [u]intmax_t. > Both of them destroy the point of intmax_t, providing a type that's > guaranteed to be the longest integer type. Should intmax_t be > deprecated? In my opinion, yes - it should be deprecated. But of course you'd want to check with people who actually use it, to see why the use it and whether there are better alternatives. > > Perhaps some future version of C might have enough capabilities to > allow defining a longest integer type without causing ABI issues > the way intmax_t did. > > And since, as far as I've been able to tell, no implementation > supports extended integer types, I wonder if they should be > reconsidered. > Maybe it would be worth reconsidering exactly what the definition of "integer type" should be in the C and C++ standards (keeping both languages in sync here is, I think, important). I'd like to see intmax_t removed and the definition of "integer type" modified such that gcc's __int128 /is/ an extended integer type. After all, people use it as though it were, and assume it is.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2021-06-01 14:05 +0200 |
| Message-ID | <ihmm3pF4hgjU1@mid.individual.net> |
| In reply to | #80034 |
On 2021-06-01 at 08:29, David Brown wrote: > On 31/05/2021 23:43, Keith Thompson wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> On 31/05/2021 00:15, daniel...@gmail.com wrote: >>>> On Saturday, May 29, 2021 at 5:47:50 AM UTC-4, David Brown wrote: >>>>> The definition of intmax_t is a problem - it is a limitation for integer >>>>> types in C and C++. Hopefully eventually deprecate intmax_t. >>>> >>>> One proposal is to make intmax_t mean int64_t, and leave it at that. >>>> Have no requirement that integer types can't be larger. No more ABI >>>> problem. >>> >>> It might make more sense to tie it to "long long int" rather than >>> "int64_t", but someone would first have to check if it affected any real >>> implementations before making such a change. But yes, that might be a >>> way out and a way forward. >> >> [...] >> >> That would allow intmax_t to be 128 bits on implementations with >> 128-bit long long (are there any?), which seems like a good idea. >> >> I think the point of both these proposals is purely for backward >> compatibility, avoiding breaking code that already uses [u]intmax_t. >> Both of them destroy the point of intmax_t, providing a type that's >> guaranteed to be the longest integer type. Should intmax_t be >> deprecated? > > In my opinion, yes - it should be deprecated. But of course you'd want > to check with people who actually use it, to see why the use it and > whether there are better alternatives. Nowadays it is very likely long long, for "reasonably wide integer type". But that hasn't always been available. > >> >> Perhaps some future version of C might have enough capabilities to >> allow defining a longest integer type without causing ABI issues >> the way intmax_t did. >> >> And since, as far as I've been able to tell, no implementation >> supports extended integer types, I wonder if they should be >> reconsidered. >> > > Maybe it would be worth reconsidering exactly what the definition of > "integer type" should be in the C and C++ standards (keeping both > languages in sync here is, I think, important). I'd like to see > intmax_t removed and the definition of "integer type" modified such that > gcc's __int128 /is/ an extended integer type. After all, people use it > as though it were, and assume it is. > And it really *is*, except for the documentation saying "integer type extension" (and not "extended integer type"), only to avoid the intmax_t problem.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-01 15:58 +0200 |
| Message-ID | <s95edd$a8p$2@dont-email.me> |
| In reply to | #80041 |
On 01/06/2021 14:05, Bo Persson wrote: > On 2021-06-01 at 08:29, David Brown wrote: >> On 31/05/2021 23:43, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>>> On 31/05/2021 00:15, daniel...@gmail.com wrote: >>>>> On Saturday, May 29, 2021 at 5:47:50 AM UTC-4, David Brown wrote: >>>>>> The definition of intmax_t is a problem - it is a limitation for >>>>>> integer >>>>>> types in C and C++. Hopefully eventually deprecate intmax_t. >>>>> >>>>> One proposal is to make intmax_t mean int64_t, and leave it at that. >>>>> Have no requirement that integer types can't be larger. No more ABI >>>>> problem. >>>> >>>> It might make more sense to tie it to "long long int" rather than >>>> "int64_t", but someone would first have to check if it affected any >>>> real >>>> implementations before making such a change. But yes, that might be a >>>> way out and a way forward. >>> >>> [...] >>> >>> That would allow intmax_t to be 128 bits on implementations with >>> 128-bit long long (are there any?), which seems like a good idea. >>> >>> I think the point of both these proposals is purely for backward >>> compatibility, avoiding breaking code that already uses [u]intmax_t. >>> Both of them destroy the point of intmax_t, providing a type that's >>> guaranteed to be the longest integer type. Should intmax_t be >>> deprecated? >> >> In my opinion, yes - it should be deprecated. But of course you'd want >> to check with people who actually use it, to see why the use it and >> whether there are better alternatives. > > Nowadays it is very likely long long, for "reasonably wide integer > type". But that hasn't always been available. > > >> >>> >>> Perhaps some future version of C might have enough capabilities to >>> allow defining a longest integer type without causing ABI issues >>> the way intmax_t did. >>> >>> And since, as far as I've been able to tell, no implementation >>> supports extended integer types, I wonder if they should be >>> reconsidered. >>> >> >> Maybe it would be worth reconsidering exactly what the definition of >> "integer type" should be in the C and C++ standards (keeping both >> languages in sync here is, I think, important). I'd like to see >> intmax_t removed and the definition of "integer type" modified such that >> gcc's __int128 /is/ an extended integer type. After all, people use it >> as though it were, and assume it is. >> > > And it really *is*, except for the documentation saying "integer type > extension" (and not "extended integer type"), only to avoid the intmax_t > problem. There is also no way to make constant literals of __int128, nor is there support for printf and a wide variety of the builtin functions, and standard library functions, and other bits and pieces. It's fine for basic usage, but missing many features of int64_t and other sized integer types. (I'm not complaining, just noting.)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-06-01 11:33 -0400 |
| Message-ID | <s95k0j$ipt$1@dont-email.me> |
| In reply to | #80042 |
On 6/1/21 9:58 AM, David Brown wrote: > On 01/06/2021 14:05, Bo Persson wrote: >> On 2021-06-01 at 08:29, David Brown wrote: ... >>> Maybe it would be worth reconsidering exactly what the definition of >>> "integer type" should be in the C and C++ standards (keeping both >>> languages in sync here is, I think, important). I'd like to see >>> intmax_t removed and the definition of "integer type" modified such that >>> gcc's __int128 /is/ an extended integer type. After all, people use it >>> as though it were, and assume it is. >>> >> >> And it really *is*, except for the documentation saying "integer type >> extension" (and not "extended integer type"), only to avoid the intmax_t >> problem. > > There is also no way to make constant literals of __int128, nor is there > support for printf and a wide variety of the builtin functions, and > standard library functions, and other bits and pieces. It's fine for > basic usage, but missing many features of int64_t and other sized > integer types. (I'm not complaining, just noting.) > If they changed their documentation to identify __int128_t as an extended integer type, then they would be required to support int128_t, along with all of the corresponding features of <cinttypes> and <cstdint>, which would address that issue.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-06-01 10:52 -0700 |
| Message-ID | <87mts9xyiv.fsf@nosuchdomain.example.com> |
| In reply to | #80045 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 6/1/21 9:58 AM, David Brown wrote:
>> On 01/06/2021 14:05, Bo Persson wrote:
>>> On 2021-06-01 at 08:29, David Brown wrote:
> ...
>>>> Maybe it would be worth reconsidering exactly what the definition of
>>>> "integer type" should be in the C and C++ standards (keeping both
>>>> languages in sync here is, I think, important). I'd like to see
>>>> intmax_t removed and the definition of "integer type" modified such that
>>>> gcc's __int128 /is/ an extended integer type. After all, people use it
>>>> as though it were, and assume it is.
>>>>
>>>
>>> And it really *is*, except for the documentation saying "integer type
>>> extension" (and not "extended integer type"), only to avoid the intmax_t
>>> problem.
>>
>> There is also no way to make constant literals of __int128, nor is there
>> support for printf and a wide variety of the builtin functions, and
>> standard library functions, and other bits and pieces. It's fine for
>> basic usage, but missing many features of int64_t and other sized
>> integer types. (I'm not complaining, just noting.)
>
> If they changed their documentation to identify __int128_t as an
> extended integer type, then they would be required to support int128_t,
> along with all of the corresponding features of <cinttypes> and
> <cstdint>, which would address that issue.
*And* they'd have to make intmax_t 128 bits, which would cause more
problems.
--
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]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-05-27 23:16 -0400 |
| Message-ID | <s8pn9v$nad$1@dont-email.me> |
| In reply to | #79814 |
On 5/27/21 7:17 PM, Lynn McGuire wrote: > On 5/27/2021 5:58 PM, Keith Thompson wrote: ... >> The above is correct in C, but not in C++, which makes an additional >> guarantee that C doesn't. C++17 21.2.4 [support.types.layout] says: >> >> The type size_t is an implementation-defined unsigned integer type >> that is large enough to contain the size in bytes of any object >> (8.3.3). > > Except the actual size of a FILE * object in the filesystem. I think you mean the actual size of the file associated with the FILE* object. A FILE* object is simply a pointer. A FILE object is typically a struct object whose members contain the information needed by <cstdio> functions to manage access to that file. In particular, it generally contains a pointer to a dynamically allocated buffer which is used to store parts of the file as they are being read from or written to the file. It does not normally store the entire contents of the file.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-05-28 14:34 +0000 |
| Message-ID | <1c7sI.86483$RC2.76963@fx27.iad> |
| In reply to | #79814 |
Lynn McGuire <lynnmcguire5@gmail.com> writes: >On 5/27/2021 5:58 PM, Keith Thompson wrote: >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >> The above is correct in C, but not in C++, which makes an additional >> guarantee that C doesn't. C++17 21.2.4 [support.types.layout] says: >> >> The type size_t is an implementation-defined unsigned integer type >> that is large enough to contain the size in bytes of any object >> (8.3.3). > >Except the actual size of a FILE * object in the filesystem. Size_t can >hold the size of the FILE * structure but if the actual file size is >greater than 4 GB in a Win32 program, size_t will be wrong. The size of a file is defined by off_t, not size_t.
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2021-05-27 18:19 -0500 |
| Message-ID | <s8p9da$gun$2@dont-email.me> |
| In reply to | #79810 |
On 5/27/2021 5:58 PM, Keith Thompson wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>>> On 5/27/2021 12:50 AM, Christian Gollwitzer wrote:
>>>>> Am 26.05.21 um 20:32 schrieb Lynn McGuire: - Alf
>>>>>>
>>>>>> I have already replaced the fell code with _ftelli64.
>>>>>>
>>>>>> //Â get the size of the output file
>>>>>> fseek (pOutputFile, 0, SEEK_END);
>>>>>> __int64 outputFileLength = _ftelli64 (pOutputFile) + 42;Â // give it
>>>>>> some slop
>>>>>> int outputFileLengthInt = (int) outputFileLength;
>>>>>
>>>>> ...and here you restrict it to 2GB again, or worse, retrieve a negative
>>>>> file size for sizes between 2GB and 4GB.
>>>>>
>>>>>
>>>>> To prepare for a 64bit move, you should replace all size variables with
>>>>> size_t for unsigned or ptrdiff_t for signed. That will correspond to a
>>>>> 32bit integer in 32 bit and a 64 bit integer in 64 bit.
>>>>>
>>>>> Â Â Â Â Christian
>>>>
>>>> Done. With checking against SIZE_MAX before casting the variable to size_t.
>>>
>>> Why? size_t is guaranteed to hold the size of any object, which implies that
>>> it must be large enough to accomodate an object the size of the virtual address
>>> space. Generally it's minimum size in bits is the same as long.
>>
>> That's likely to be true, but it's not absolutely guaranteed.
>
> My apologies, I was wrong.
>
>> size_t is intended to hold the size of any single object, but it may
>> not be able to hold the sum of sizes of all objects or the size of
>> the virtual address space. An implementation might restrict the
>> size of any single object to something smaller than the size of
>> the entire virtual address space. (Think segments.)
>
> I believe this is still correct.
>
>> Also, I haven't found anything in the standard that says you
>> can't at least try to create an object bigger than SIZE_MAX bytes.
>> calloc(SIZE_MAX, 2) attempts to allocate such an object, and I don't
>> see a requirement that it must fail. If an implementation lets you
>> define a named object bigger than SIZE_MAX bytes, then presumably
>> applying sizeof to it would result in an overflow, and therefore
>> undefined behavior.
>>
>> Any reasonable implementation will simply make size_t big enough
>> to hold the size of any object it can create, but I don't see a
>> requirement for it.
>
> The above is correct in C, but not in C++, which makes an additional
> guarantee that C doesn't. C++17 21.2.4 [support.types.layout] says:
>
> The type size_t is an implementation-defined unsigned integer type
> that is large enough to contain the size in bytes of any object
> (8.3.3).
Here is the definition for SIZE_MAX:
#ifndef SIZE_MAX
#ifdef _WIN64
#define SIZE_MAX _UI64_MAX
#else
#define SIZE_MAX UINT_MAX
#endif
#endif
Lynn
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-05-28 03:47 +0200 |
| Message-ID | <s8pi3b$v7f$1@dont-email.me> |
| In reply to | #79808 |
> size_t is intended to hold the size of any single object, but it may > not be able to hold the sum of sizes of all objects or the size of > the virtual address space. ... You are an absolute nutcase. size_t is the same size as a pointer on all systems with flat memory, so you can use it to assume the size of any object. > the virtual address space. An implementation might restrict the > size of any single object to something smaller than the size of > the entire virtual address space. (Think segments.) There is no such implementation with flat memory and there won't be such system in the future because there's no reason to design a plat- form in that way.
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2021-05-27 17:45 -0500 |
| Message-ID | <s8p7di$5qk$1@dont-email.me> |
| In reply to | #79807 |
On 5/27/2021 4:59 PM, Scott Lurndal wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>> On 5/27/2021 12:50 AM, Christian Gollwitzer wrote:
>>> Am 26.05.21 um 20:32 schrieb Lynn McGuire: - Alf
>>>>
>>>> I have already replaced the fell code with _ftelli64.
>>>>
>>>> // get the size of the output file
>>>> fseek (pOutputFile, 0, SEEK_END);
>>>> __int64 outputFileLength = _ftelli64 (pOutputFile) + 42; // give it
>>>> some slop
>>>> int outputFileLengthInt = (int) outputFileLength;
>>>
>>> ...and here you restrict it to 2GB again, or worse, retrieve a negative
>>> file size for sizes between 2GB and 4GB.
>>>
>>>
>>> To prepare for a 64bit move, you should replace all size variables with
>>> size_t for unsigned or ptrdiff_t for signed. That will correspond to a
>>> 32bit integer in 32 bit and a 64 bit integer in 64 bit.
>>>
>>> Christian
>>
>> Done. With checking against SIZE_MAX before casting the variable to size_t.
>
> Why? size_t is guaranteed to hold the size of any object, which implies that
> it must be large enough to accomodate an object the size of the virtual address
> space. Generally it's minimum size in bits is the same as long.
// get the size of the output file
fseek (pOutputFile, 0, SEEK_END);
__int64 outputFileLength = _ftelli64 (pOutputFile) + 42; // give it
some slop
size_t outputFileLengthSizeT = 0;
if (outputFileLength < SIZE_MAX)
outputFileLengthSizeT = (size_t) outputFileLength;
fseek (pOutputFile, 0, SEEK_SET);
// need to preallocate the space in case the output file is a gigabyte
or more, PMR 6408
// if the try fails then just don't store the output file in the flowsheet
if (outputFileLengthSizeT > 0)
{
try
{
// PMR 6408 will cause this to fail
outputFileBuffer.reserve (outputFileLengthSizeT);
Thanks,
Lynn
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-05-28 14:38 +0000 |
| Message-ID | <4g7sI.86484$RC2.22910@fx27.iad> |
| In reply to | #79809 |
Lynn McGuire <lynnmcguire5@gmail.com> writes:
>On 5/27/2021 4:59 PM, Scott Lurndal wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>> On 5/27/2021 12:50 AM, Christian Gollwitzer wrote:
>>>> Am 26.05.21 um 20:32 schrieb Lynn McGuire: - Alf
>>>>>
>>>>> I have already replaced the fell code with _ftelli64.
>>>>>
>>>>> // get the size of the output file
>>>>> fseek (pOutputFile, 0, SEEK_END);
>>>>> __int64 outputFileLength = _ftelli64 (pOutputFile) + 42; // give it
>>>>> some slop
>>>>> int outputFileLengthInt = (int) outputFileLength;
>>>>
>>>> ...and here you restrict it to 2GB again, or worse, retrieve a negative
>>>> file size for sizes between 2GB and 4GB.
>>>>
>>>>
>>>> To prepare for a 64bit move, you should replace all size variables with
>>>> size_t for unsigned or ptrdiff_t for signed. That will correspond to a
>>>> 32bit integer in 32 bit and a 64 bit integer in 64 bit.
>>>>
>>>> Christian
>>>
>>> Done. With checking against SIZE_MAX before casting the variable to size_t.
>>
>> Why? size_t is guaranteed to hold the size of any object, which implies that
>> it must be large enough to accomodate an object the size of the virtual address
>> space. Generally it's minimum size in bits is the same as long.
>
> // get the size of the output file
You have a fundamental misunderstanding. A file isn't an object
from the C standard perspective.
struct stat {
dev_t st_dev; /* ID of device containing file */
ino_t st_ino; /* Inode number */
mode_t st_mode; /* File type and mode */
nlink_t st_nlink; /* Number of hard links */
uid_t st_uid; /* User ID of owner */
gid_t st_gid; /* Group ID of owner */
dev_t st_rdev; /* Device ID (if special file) */
off_t st_size; /* Total size, in bytes */
blksize_t st_blksize; /* Block size for filesystem I/O */
blkcnt_t st_blocks; /* Number of 512B blocks allocated */
struct timespec st_atim; /* Time of last access */
struct timespec st_mtim; /* Time of last modification */
struct timespec st_ctim; /* Time of last status change */
#define st_atime st_atim.tv_sec /* Backward compatibility */
#define st_mtime st_mtim.tv_sec
#define st_ctime st_ctim.tv_sec
};
File sizes use the 'off_t' type.
If windows did not define an off_t equivelent, then the windows API
is insufficient.
From the compiler perspective, size_t applies only to in-memory objects.
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.c++
csiph-web