Skip to content
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.

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

Printf.printf and related functions do not take precision argument for strings #6942

Closed
vicuna opened this issue Jul 29, 2015 · 6 comments
Closed

Comments

@vicuna
Copy link

@vicuna vicuna commented Jul 29, 2015

Original bug ID: 6942
Reporter: acascella
Status: acknowledged (set by @damiendoligez on 2016-11-08T10:19:06Z)
Resolution: open
Priority: low
Severity: feature
Platform: x86_64
OS: GNU/Linux
OS Version: 3.13.0-57-generi
Version: 4.02.2
Category: standard library
Monitored by: @gasche

Bug description

I noticed that precision in formatters for strings is ignored. For instance Printf.printf "%.2" "Hello" will print "Hello".

In C, the equivalent call would print only the first two chars, "He". The precision is interpreted as the maximum number of bytes to be written to the output.

I know that the OCaml documentation for Printf doesn't specify the behavior of precision for strings, so this is not a bug. I was only wondering if there is a reason for not handling precision for strings, or if it will be a desirable feature to add.

Steps to reproduce

OCaml version 4.02.2

Printf.printf "%s" "Hello";;

Hello- : unit = ()

Printf.printf "%.2s" "Hello" ;;

Hello- : unit = ()

@vicuna
Copy link
Author

@vicuna vicuna commented Jul 29, 2015

Comment author: @gasche

Note that both "%10s" "%.10s" pad when the input string is less than 10 characters (and you can use "-" for padding to the right, but 0-padding is ignored). The part that was never implemented is cutting the input when the width specification is smaller than the string size.

@vicuna
Copy link
Author

@vicuna vicuna commented Jul 29, 2015

Comment author: acascella

The part that was never implemented is cutting the input when the width specification is smaller than the string size.

Actually specifying a width smaller than the size of the string has no effect:

printf("%2s", "Hello") will print "Hello".

The width gives the minimum width of the field.
The precision the maximum number of bytes to write.

The format '%x.ys' will print at most y chars into a field of size x, padding with spaces if needed.

On the other side, if a precision is given, the cutting takes place whatever the width specified, before eventually padding to the minimum width.

printf("%10.2s", "Hello") will print "________He". (where _ = space).

So it would be useful to have both width and precision in string formats.

@vicuna
Copy link
Author

@vicuna vicuna commented Jul 29, 2015

Comment author: bvaugon

This feature may be easy to implement, I think, and sometimes useful.
Another useful feature may be to print ellipsis when the string is
truncated.

However, remarks that truncating a string "anywhere" is "dangerous"
when you print (for example) some utf8 data because you may truncate a
multi-byte character.

@vicuna
Copy link
Author

@vicuna vicuna commented Jul 29, 2015

Comment author: @gasche

One think I like with this proposal is that at least it gives a clear specification of what the padding and precision numbers do for non-floating-point parameters.

@vicuna
Copy link
Author

@vicuna vicuna commented Jul 31, 2015

Comment author: acascella

@bvaugon: you're right, truncation should be done by number of chars and not bytes, in order to avoid that kind of problem with multi-byte characters.

@gasche: I think it is a good idea to use the C specification, which is clear and precise, when possible. (You can have a look at http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf starting page 274 for the printf family functions).

@github-actions
Copy link

@github-actions github-actions bot commented May 11, 2020

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label May 11, 2020
@github-actions github-actions bot closed this Jun 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant