Re: [Tclap-discuss] Sign conversion errors

[Daniel A. <dan...@gm...>]

Oh, and as for SF vs GitHub, there is a (not always updated) mirror at
https://github.com/DAarno/tclap. I've just been on SF for so long, I've not
seen a strong reason to spend the effort to move everything over - but
maybe someday...

On Sun, Apr 19, 2020 at 7:02 PM Daniel Aarno <dan...@gm...> wrote:

> I looked at merging
> https://github.com/boxerab/tclap/commit/dd2c7b6faa13ad74bce2bfe26e5483e62186ed6c.
> Is there any reason why it's adding back XorHandler.h
> and ZshCompletionOutput.h?
>
> On Wed, Apr 15, 2020 at 3:49 PM Aaron Boxer <bo...@gm...> wrote:
>
>>
>>
>> On Wed, Apr 15, 2020 at 8:47 AM Daniel Aarno <dan...@gm...>
>> wrote:
>>
>>> I'm aware of these, I think VS also emits these warnings. I've
>>> considered fixing these multiple times over the years (they are all OK btw)
>>> but in some places changing to unsigned may actually lead to *more* bugs
>>> due to potential wrap-around issues (i.e., where the code expects that
>>> results can be negative) - so some care needs to be taken. In general use
>>> of unsigned ints should be discouraged when the only purpose is to signal
>>> that a value is never less than zero and I believe most folks these days
>>> agree that it was a mistake to use unsigned ints in STL containers.
>>>
>>> That said, in some places the fix is actually trivial and should
>>> probably be done (it's just that nobody except me has cared about it so
>>> far) - so if you want to send some patches to fix these, I'm happy to
>>> review.
>>>
>>> For example, this is just ridiculous:
>>>
>>> inline void Arg::trimFlag(std::string& flag, std::string& value) const
>>>
>>> {
>>>
>>>     int stop = 0;
>>>
>>>     for ( int i = 0; static_cast<unsigned int>(i) < flag.length(); i++ )
>>>
>>>         if ( flag[i] == Arg::delimiter() )
>>>
>>> ...
>>>
>>>
>> Note: Re-sending because I got a warning from SF about length of original
>> reply:
>>
>> Yes, exactly. I have a patch here:
>>
>> https://github.com/boxerab/tclap/tree/warnings
>>
>> By the way, I would highly recommend moving the project to Github or
>> Gitlab.
>> Workflow is so much nicer, and you don't get bombarded by SF ads.
>> I was very hesitiant to register with SF discussion list.
>>
>> It would probably only take a few hours to sign up and migrate the repo.
>> Not sure about issue migration.
>>
>> Just my 2 cents :)
>>
>>