Skip to content

Conversation

@thedax
Copy link
Contributor

@thedax thedax commented Sep 24, 2018

On Windows, longs (as specified by %lX) are 32-bit, not 64-bit, so assuming its size results in the upper 32-bits of the title id being lost.

Appears to still work fine on Linux (tested on Antergos) and macOS.

gcc (this output is from clang, but it should also output with -Wall on gcc) also warns about this:

~/s/src> gcc nacptool.c
nacptool.c:82:89: warning: format specifies type 'unsigned long *' but the
      argument has type 'u64 *' (aka 'unsigned long long *') [-Wformat]
  ..."--titleid=", 10)==0) sscanf(&argv[argi][10], "%016lX", &titleid);
                                                    ~~~~~~   ^~~~~~~~
                                                    %16llX
1 warning generated.

Shoutout to @jakibaki for testing on macOS.

On Windows, longs (as specified by %lX) are 32-bit, not 64-bit, so assuming its size results in the upper 32-bits of the title id being lost.
@fincs
Copy link
Contributor

fincs commented Sep 24, 2018

Instead of hardcoding the format specifier, inttypes.h should be included and SCNX64 should be used instead.

@thedax
Copy link
Contributor Author

thedax commented Sep 24, 2018

Sure, one sec.

@fincs
Copy link
Contributor

fincs commented Sep 24, 2018

SCNx64 != SCNX64 btw.

@thedax
Copy link
Contributor Author

thedax commented Sep 24, 2018

That doesn't seem to exist, hence why I used SCNx64.

if (strncmp(argv[argi], "--titleid=", 10) == 0) sscanf(&argv[argi][10], "%016" SCNX64, &titleid);

Windows and Linux both complain:
missing ')' before identifier 'SCNX64'

It's also not in Windows's version of inttypes.h (admittedly, I only checked VS2017 here, I do not have mingw or cygwin set up), nor Antergos Linux's. Did I miss something here?

@fincs
Copy link
Contributor

fincs commented Sep 24, 2018

I see. Somehow I had googled one version of this file and it did have SCNX64 in it. Alright then.

@yellows8
Copy link
Collaborator

Is using PRIX64 an option since SCNX64 isn't available?

@fincs
Copy link
Contributor

fincs commented Sep 24, 2018

It's technically invalid to use PRI codes for scanf.

@yellows8
Copy link
Collaborator

Is there a proper way to keep using uppercase-hex?(Wouldn't changing to lowercase break input which uses uppercase?)

@jakibaki
Copy link

Is there a proper way to keep using uppercase-hex?(Wouldn't changing to lowercase break input which uses uppercase?)

I just checked and at least on macOS the %llx works with lower, upper and mixed-case hex-strings.

@yellows8
Copy link
Collaborator

(Using "x" is fine if it's still compat with uppercase on all platforms)

@yellows8 yellows8 merged commit 3c91ce8 into switchbrew:master Oct 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants