From: Daniel A. <dan...@gm...> - 2020-04-19 18:02:25
|
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 :) > > |