Skip to content

fmt: is %% a literal percent, or a degenerate conversion? #71384

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
adonovan opened this issue Jan 22, 2025 · 5 comments
Open

fmt: is %% a literal percent, or a degenerate conversion? #71384

adonovan opened this issue Jan 22, 2025 · 5 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Backlog

Comments

@adonovan
Copy link
Member

During the review of the printf format-string parser used by gopls (extracted from the one in vet's printf checker), the question arose as to whether %% is nothing more than a literal percent sign, dealt with by the printf scanner, or a degenerate conversion supporting width, flags, precision, and so on.

Empirically, the surprising answer is that it is very much a conversion. Observe that it accepts a width, even indirectly, and updates the argument index accordingly (though it doesn't actually left-pad the output):

https://go.dev/play/p/Z4s7oV2HIM7

var unused any
width := 456
v := 789
fmt.Printf("%[2]*[4]% %v", unused, width, unused, v) // "% 789"

(Either way this seems wrong: the argument at index 4 should either be rejected or consumed by the %%; instead it becomes the operand of %v.)

Aside: I checked C for precedent, and found that it too empirically treats %% as a conversion:

$ cat a.c
#include <stdio.h>
int main() { printf("%10.2%%d\n", 4); }
$ gcc a.c && ./a.out
         %4

Notice the left-padding to ten spaces. However, this program has undefined behavior according to POSIX.1:

Print a '%' character; no argument is converted. The complete conversion specification shall be %%.

What is the intended behavior for Go?
@gabyhelp
Copy link

Related Issues

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

@gabyhelp gabyhelp added the LanguageProposal Issues describing a requested change to the Go language specification. label Jan 22, 2025
@ianlancetaylor
Copy link
Member

CC @robpike

I think it's pretty clear from your note that the Go behavior at this point is what it is, especially since it roughly matches the C behavior. That is, I don't think there is any action to take here.

@adonovan
Copy link
Member Author

I think it's pretty clear from your note that the Go behavior at this point is what it is, especially since it roughly matches the C behavior.

Roughly matches the behavior of a particular C compiler on a program with undefined behavior. ;-)

I don't think there is any action to take here.

It may not be too late to produce a !BAD output in this case; but if we choose to allow it, then we should fix the off-by-one error in the computation of the argument indices. Either way, we should at least document the intent.

@jba jba removed the LanguageProposal Issues describing a requested change to the Go language specification. label Jan 22, 2025
@robpike
Copy link
Contributor

robpike commented Jan 22, 2025

I think, as Ian said, it is what it is. As far as I remember there was no deliberate attempt to do anything in particular. I may have compared it to what gcc does; that's what I usually used when I had questions. Or it may just have turned out this way.

I don't think it matters and I sincerely believe nothing needs to be done.

@cagedmantis cagedmantis added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 27, 2025
@cagedmantis cagedmantis added this to the Backlog milestone Jan 27, 2025
@seankhliao
Copy link
Member

related #22868

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
7 participants
@cagedmantis @ianlancetaylor @robpike @adonovan @seankhliao @jba @gabyhelp