Flags().Uin64P broken - Githubissues

spf13 / cobra

A Commander for modern Go CLI interactions

https://cobra.dev

Apache License 2.0

37.66k stars 2.83k forks source link

Flags().Uin64P broken #1869

Open blacktop opened 1 year ago

blacktop commented 1 year ago

ToUintE() fails to parse uint bigger than math.MaxInt64 in the cast dependancy. This prevents people from using numbers like macOS kernel addresses as arguents to cobra:

example:

❯ ipsw macho disass test-caches/IPSWs/20C5058d__iPhone15,2/kernelcache.release.iPhone15,2 -a 0xFFFFFFF008493FE0 -V --fileset-entry com.apple.AGXFirmwareKextG15P_A0RTBuddy

fails because it thinks I entered 0 as the --vaddr (virtual address) to be disassembled

marckhouzam commented 1 year ago

Does this issue belong in https://github.com/spf13/pflag which does the flag parsing for Cobra?

memreflect commented 1 year ago

There are no issues with pflag's handling of uint64, nor Cobra's usage of pflag: Playground demo. It is Viper that uses the cast package, which is probably why you are seeing a problem. Here is a Playground demo that confirms the difference, though the build will likely time out due to Viper's dependency chain.

PR spf13/cast#155 just needs to be merged to fix Cobra CLIs that rely on Viper.

memreflect commented 1 year ago

I forgot to mention that if you need a temporary workaround until things get fixed, you can vendor your module's dependencies and swap the copy of caste.go in the vendor directory for the one in the PR. You'll also want to commit the vendor directory to your repository. That way, your packages and their dependencies that use cast will work as they should, even when they're installed using go install or go get.

blacktop commented 1 year ago

@memreflect thank you SO much for taking the time to triage this!! ❤️ AND for writing such a clear and concise example PoC 👍

github-actions[bot] commented 1 year ago

The Cobra project currently lacks enough contributors to adequately respond to all issues. This bot triages issues and PRs according to the following rules:

After 60d of inactivity, lifecycle/stale is applied. - After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied and the issue is closed. You can:
Make a comment to remove the stale label and show your support. The 60 days reset. - If an issue has lifecycle/rotten and is closed, comment and ask maintainers if they'd be interested in reopening

blacktop commented 1 year ago

ping