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

Groups > comp.lang.c++ > #79816

Re: recovering from std::bad_alloc in std::string reserve

Path csiph.com!news.swapon.de!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups comp.lang.c++
Subject Re: recovering from std::bad_alloc in std::string reserve
Date Thu, 27 May 2021 16:58:02 -0700
Organization None to speak of
Lines 96
Message-ID <87k0njzq45.fsf@nosuchdomain.example.com> (permalink)
References <s8hkt2$liv$1@dont-email.me> <s8lt9d$tf0$1@dont-email.me> <s8m48i$g6f$3@dont-email.me> <s8nbvd$5ah$1@dont-email.me> <s8oqn6$fbj$1@dont-email.me> <_CUrI.452334$ST2.205157@fx47.iad> <87sg27zu0i.fsf@nosuchdomain.example.com> <87o8cvzsux.fsf@nosuchdomain.example.com> <s8p9ak$gun$1@dont-email.me>
Mime-Version 1.0
Content-Type text/plain; charset=utf-8
Content-Transfer-Encoding 8bit
Injection-Info reader02.eternal-september.org; posting-host="1458d77179aa98232e45e826606b1dc8"; logging-data="27210"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19OfAbS+kxYsOvOEUiah5Lz"
User-Agent Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
Cancel-Lock sha1:Pz5y3TR5Rll+GjylsJJFIGMViG4= sha1:6DlTQZ8EgbfufNdjK383xLBwFT0=
Xref csiph.com comp.lang.c++:79816

Show key headers only | View raw

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:
>>> 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).
>
> 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.

A FILE* object is a pointer, likely 4 or 8 bytes.  A FILE object is
probably a struct, 216 bytes on my system.

> Now if the program is Win64, size_t can hold the actual size of any
> file in the filesystem.
>
> #ifdef _WIN64
>     typedef unsigned __int64 size_t;
>     typedef __int64          ptrdiff_t;
>     typedef __int64          intptr_t;
> #else
>     typedef unsigned int     size_t;
>     typedef int              ptrdiff_t;
>     typedef int              intptr_t;
> #endif

size_t isn't for representing sizes of files, which are not objects.
In fact C doesn't define a type for representing file sizes.
(It might be nice if it did.)  ftell() returns a long, which is not
big enough on systems with 32-bit long (and reasonable file systems).
fgetpos gives you an fpos_t, which isn't necessarily an integer type.

You can use long long or unsigned long long, guaranteed to be at least
64 bits (or [u]int64_t, or [u]intmax_t).

-- 
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 */

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web