Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c++
Subject: Re: This code is effective for modest-sized numbers, but can you tell what it does?
Date: Fri, 29 Apr 2022 16:12:32 -0700
Organization: A noiseless patient Spider
Lines: 41
Message-ID: <868rrn5vrz.fsf@linuxsc.com>
References: <0c3601f0-fc8c-4bb9-a8b3-598ea1ca4a79n@googlegroups.com> <t45cmv$1omi$1@gioia.aioe.org> <86fsm18i1c.fsf@linuxsc.com> <1e7dce56-0c33-4b7b-b013-9e6bac199566n@googlegroups.com> <t47vee$10e7$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="947a81ba8a661bedfa1d3062f5b6bffa"; logging-data="4765"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+Sh8BfTlM3pczmu3Ttm4WYHrmJMUMoRuw="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:31UQDTJhT1rc6+aK420ANoVdV1Q= sha1:kNS0pBoLUsFKxe2R7mEBqCbK1rg=
Xref: csiph.com comp.lang.c++:83887

Juha Nieminen <nospam@thanks.invalid> writes:

>  <<D6 F6 [05b6]>>  Tiib <ootiib@hot.ee> wrote:
>
>> On Monday, 25 April 2022 at 15:27:42 UTC+3, Tim Rentsch wrote:
>>
>>> Juha Nieminen <nos...@thanks.invalid> writes:
>>>
>>>> Graeme C. <gra...@gmail.com> wrote:
>>>
>>> [...]
>>>
>>>>> for (int i=0; i<vf[gen-1].size(); i++) { // from previous gen
>>>>
>>>> std::vector::size() returns a value of type std::size_t.  You
>>>> shouldn't be using an int with it.
>>>
>>> I don't want to start a holy war, but in this particular case
>>> there is no problem comparing a signed type to a size_t (which is
>>> an unsigned type).  More generally, whenever a value of a signed
>>> type has a non-negative value, as is obviously true in this
>>> construct, then there is never a problem comparing a value of a
>>> signed type to a value of an unsigned type.
>>>
>>> Some people prefer using an unsigned type for indexing variables
>>> like 'i' above, and that a reasonable style choice here IMO.  But
>>> there is nothing logically wrong with giving 'i' a signed type
>>> here instead.
>>
>> The issue as I read it was about chance that int is 32 bits, the
>> vf[gen-1] has 2,200,000,000 elements and so the ++ will be
>> applied to INT_MAX  that is undefined behavior.
>
> Yeah, it's not that much about the signedness, but about the size.
> After all, the program accepts a 'long long' value as input, so
> ostensibly the vector might have more than INT_MAX and even more
> than UINT_MAX elements (might not be the case with this particular
> program, I haven't checked, but in general it could be).

Does this mean that if the loop variable 'i' had been given type
'long long' then you would have no complaints?