why they use the word modifies in c

[Karel]

I started an attempt to use the standardized datatypes and I got the following problem when
changing a "long long int" to int64_t related to printf():

Code: [Select]

warning: format ‘%lli’ expects argument of type ‘long long int’, but argument 4 has type ‘int64_t {aka long int}’ [-Wformat=]
I don't want to disable -Wformat but I do want to get rid from the warning. Is there a solution?

[madires]

(long long int)my_variable

[Karel]

(long long int)my_variable

You are right ofcourse but it doesn't look very elegant. Why is int64_t a typedef from long int?
Why not long long int instead?

[newbrain]

Code: [Select]

warning: format ‘%lli’ expects argument of type ‘long long int’, but argument 4 has type ‘int64_t {aka long int}’ [-Wformat=]I don't want to disable -Wformat but I do want to get rid from the warning. Is there a solution?

Yes, there is.
As the actual type underlying (u)int??_t is not generally known (apart from (u)int8_t, that is forcibly a char type as discussed above), the standard provides, in its slightly less than infinite wisdom  , type specific conversion specifiers as macros in chapter 7.8.1 "Macros for format specifiers" (same chapter for C99, C11 and C18).

They are defined as character string literals, and have a quite regular form.
In your case for an uint64_T it would be PRIu64 for printf and SCNu64 for scanf.

Being string literals, they will be concatenated with adjacent string literals in translation phase 6, and only contain the right conversion specifier, so it's up to you to provide the % and the format width and precision, e.g:

Code: [Select]

  printf("Here's my uint64_t: %20" PRIu64 "\n", my_uint64);
Edit: changed slightly imprecise language

[Karel]

Code: [Select]

warning: format ‘%lli’ expects argument of type ‘long long int’, but argument 4 has type ‘int64_t {aka long int}’ [-Wformat=]I don't want to disable -Wformat but I do want to get rid from the warning. Is there a solution?

Yes, there is.
As the actual type underlying (u)int??_t is not generally known (apart from (u)int8_t, that is forcibly a char type as discussed above), the standard provides, in its slightly less than infinite wisdom  , type specific conversion specifiers as macros in chapter 7.8.1 "Macros for format specifiers" (same chapter for C99, C11 and C18).

They are defined as character string literals, and have a quite regular form.
In your case for an uint64_T it would be PRIu64 for printf and SCNu64 for scanf.

Being string literals, they will be concatenated with adjacent string literals in translation phase 6, and only contain the right conversion specifier, so it's up to you to provide the % and the format width and precision, e.g:

Code: [Select]

  printf("Here's my uint64_t: %20" PRIu64 "\n", my_uint64);
Edit: changed slightly imprecise language

Thanks newbrain,  but that looks even less elegant and it's makes the code less readable (at least to me).
Then I prefer the type cast as proposed by madires.

[newbrain]

Thanks newbrain,  but that looks even less elegant and it's makes the code less readable (at least to me).
Then I prefer the type cast as proposed by madires.

Suit yourself  - of course the cast will work as long as you pick the longest type available.

I, personally, find cast less appealing and elegant and use them very sparingly - especially if a correct standard solution exists.
You are not alone in this: I've seen a lot of professionally written code eschewing PRIxxx in favour of casts.
Some of the coders were not even aware and changed it when shown, some did not.

[Mp3]

Thanks newbrain,  but that looks even less elegant and it's makes the code less readable (at least to me).
Then I prefer the type cast as proposed by madires.

You don't have to keep trying to prove your coding practices to us. I think this thread ran its course.

[Karel]

Thanks newbrain,  but that looks even less elegant and it's makes the code less readable (at least to me).
Then I prefer the type cast as proposed by madires.

You don't have to keep trying to prove your coding practices to us. I think this thread ran its course.

No, I don't have to. But I'm not hurting anybody either.
Honestly, I tried to "convert" a project by using the standard datatypes and I ran into all kinds of issues and that's the reason I bring it up.
I sincerely wanted to give it try and I know I can be stubborn but, and please believe me, I'm also open to better ideas.

[coppice]

Code: [Select]

warning: format ‘%lli’ expects argument of type ‘long long int’, but argument 4 has type ‘int64_t {aka long int}’ [-Wformat=]I don't want to disable -Wformat but I do want to get rid from the warning. Is there a solution?

Yes, there is.
As the actual type underlying (u)int??_t is not generally known (apart from (u)int8_t, that is forcibly a char type as discussed above), the standard provides, in its slightly less than infinite wisdom  , type specific conversion specifiers as macros in chapter 7.8.1 "Macros for format specifiers" (same chapter for C99, C11 and C18).

They are defined as character string literals, and have a quite regular form.
In your case for an uint64_T it would be PRIu64 for printf and SCNu64 for scanf.

Being string literals, they will be concatenated with adjacent string literals in translation phase 6, and only contain the right conversion specifier, so it's up to you to provide the % and the format width and precision, e.g:

Code: [Select]

  printf("Here's my uint64_t: %20" PRIu64 "\n", my_uint64);
Edit: changed slightly imprecise language

Thanks newbrain,  but that looks even less elegant and it's makes the code less readable (at least to me).
Then I prefer the type cast as proposed by madires.

That PRIu64 stuff is definitely a PITA for readability, but it is robust and portable - at least as portable as anything from the era before UTF8 can be in 2020.