precision not working properly for strings in Printf?

precision not working properly for strings in Printf?

[Quôc Peyrot]

It seems that the precision field doesn't work properly with the "s"  
type in Printf.printf:

# Printf.printf "%.2s" "qwerty";;
qwerty- : unit = ()

This should print "qw"

-- 
Best Regards,
Quôc

Re: [Caml-list] precision not working properly for strings in Printf?

[Jonathan Bryant]

On Jun 26, 2007, at 11:18 PM, Quôc Peyrot wrote:

> It seems that the precision field doesn't work properly with the  
> "s" type in Printf.printf:

It does work properly.  It's just not working the way you're  
expecting it to work.

>
> # Printf.printf "%.2s" "qwerty";;
> qwerty- : unit = ()
>
> This should print "qw"

No it shouldn't.  The width/precision specifier guarantees a  
_minimum_ length for strings, not an absolute length.  From the docs  
for Printf:

"The optional width is an integer indicating the minimal width of the  
result. For instance, %6d prints an integer, prefixing it with spaces  
to fill at least 6 characters.

The optional precision is a dot . followed by an integer indicating  
how many digits follow the decimal point in the %f, %e, and %E  
conversions. For instance, %.4f prints a float with 4 fractional  
digits."

Minimal length for width and precision doesn't apply to string  
conversions.  Here's how it works:

         Objective Caml version 3.09.3

# Printf.sprintf "%2s" "qwerty";;
- : string = "qwerty"

# Printf.sprintf "%.2s" "qwerty";;
- : string = "qwerty"

# Printf.sprintf "%5s" "a";;
- : string = "    a"

# Printf.sprintf "%.5s" "a";;
- : string = "    a"

Hope that helps.

--Jonathan

>
> -- 
> Best Regards,
> Quôc
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] precision not working properly for strings in Printf?

[Quôc Peyrot]

On Jun 27, 2007, at 5:38 AM, Jonathan Bryant wrote:

>
> On Jun 26, 2007, at 11:18 PM, Quôc Peyrot wrote:
>
>> It seems that the precision field doesn't work properly with the  
>> "s" type in Printf.printf:
>
> It does work properly.  It's just not working the way you're  
> expecting it to work.

I was just expecting it to work like the printf from the glibc:

s      If  no  l  modifier  is  present:  The  const char * argument is
	      expected to be a pointer to an array of character type  (pointer
	      to  a string).  Characters from the array are written up to (but
	      not including) a terminating NUL character; if  a  precision  is
	      specified,  no more than the number specified are written.  If a
	      precision is given, no null character need be  present;  if  the
	      precision  is  not specified, or is greater than the size of the
	      array, the array must contain a terminating NUL character.

>> # Printf.printf "%.2s" "qwerty";;
>> qwerty- : unit = ()
>>
>> This should print "qw"
>
> No it shouldn't.  The width/precision specifier guarantees a  
> _minimum_ length for strings, not an absolute length.  From the  
> docs for Printf:

As said above, this is not how printf is working in the glibc (at  
least on linux and Mac OS X). Any clue why the same convention has  
not been followed?

-- 
Best Regards,
Quôc

Re: [Caml-list] precision not working properly for strings in Printf?

[Jonathan Bryant]

On Jun 26, 2007, at 11:48 PM, Quôc Peyrot wrote:

>
> On Jun 27, 2007, at 5:38 AM, Jonathan Bryant wrote:
>
>>
>> On Jun 26, 2007, at 11:18 PM, Quôc Peyrot wrote:
>>
>>> It seems that the precision field doesn't work properly with the  
>>> "s" type in Printf.printf:
>>
>> It does work properly.  It's just not working the way you're  
>> expecting it to work.
>
> I was just expecting it to work like the printf from the glibc:
>
> s      If  no  l  modifier  is  present:  The  const char *  
> argument is
> 	      expected to be a pointer to an array of character type   
> (pointer
> 	      to  a string).  Characters from the array are written up to  
> (but
> 	      not including) a terminating NUL character; if  a   
> precision  is
> 	      specified,  no more than the number specified are written.   
> If a
> 	      precision is given, no null character need be  present;  if   
> the
> 	      precision  is  not specified, or is greater than the size of  
> the
> 	      array, the array must contain a terminating NUL character.

The OCaml standard library isn't glibc.  The implementation of the  
Printf/Scanf modules is custom, OCaml specific and tied into the  
compiler, so one should not assume the behave the same way.  They are  
not simply wrappers.  As a matter of fact, they have several other  
differences from the glibc printf family of functions (look at the  
conversion specifiers in the docs).

>
>>> # Printf.printf "%.2s" "qwerty";;
>>> qwerty- : unit = ()
>>>
>>> This should print "qw"
>>
>> No it shouldn't.  The width/precision specifier guarantees a  
>> _minimum_ length for strings, not an absolute length.  From the  
>> docs for Printf:
>
> As said above, this is not how printf is working in the glibc (at  
> least on linux and Mac OS X). Any clue why the same convention has  
> not been followed?

See above.

>
> -- 
> Best Regards,
> Quôc
>
>
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] precision not working properly for strings in Printf?

[Vincent Hanquez]

On Wed, Jun 27, 2007 at 12:11:01AM -0400, Jonathan Bryant wrote:
> The OCaml standard library isn't glibc.  The implementation of the  
> Printf/Scanf modules is custom, OCaml specific and tied into the  
> compiler, so one should not assume the behave the same way.  They are  
> not simply wrappers.  As a matter of fact, they have several other  
> differences from the glibc printf family of functions (look at the  
> conversion specifiers in the docs).
> 
> >As said above, this is not how printf is working in the glibc (at  
> >least on linux and Mac OS X). Any clue why the same convention has  
> >not been followed?
> 
> See above.

What about reading before replying ?
Your "explanation" certainly doesn't answer his question.
whether or not it's the same *implementation* doesn't answer why ocaml
printf choosed a different *convention* (specially on this case which I
don't see any contradiction in the way ocaml works).

Cheers,
-- 
Vincent Hanquez

Re: [Caml-list] precision not working properly for strings in Printf?

[Jonathan Bryant]

>
> I was just expecting it to work like the printf from the glibc:

>>> Any clue why the same convention has
>>> not been followed?
>>

Apparently my implication in my first response was not clear to some,  
so I'll clarify what I meant:

The reasons for not following standard *nix conventions is a choice  
of the language/library designer, so I cannot speak on their behalf.

I'd assume, though, that since the library was implemented from  
scratch, the conventions were not followed because it was, in some  
cases, opportune not to follow them.  For example, some glibc  
conventions do not work for OCaml (such as pointer conversions), and  
the existing conventions did not handle things such as polymorphic  
values.  In these cases, the designer simply took advantage of an  
opportunity to "fix" printf for OCaml.  There's nothing wrong with  
glibc's implementation, except that it's designed for C.

In other cases, such as the string conversion specifier, there is no  
contradiction, so maybe it's an oversight, maybe it's for consistency  
with numeric conversions, maybe it's easier to implement that way, or  
maybe it's just how the designer thought it should work.  In any  
case, that's the way the library was designed and documented and it's  
the designer's prerogative to implement it how they see fit.  The  
OCaml version is only based on glibc's printf while being designed  
specifically for OCaml, probably with the knowledge that String.sub  
is a simple function to use.

In light of the above, I think that unfortunately the answer to the  
question of "why" is actually moot in this case because it is highly  
unlikely to change given that changing it could break existing code  
(in very subtle ways, none the less).

> What about reading before replying ?
> Your "explanation" certainly doesn't answer his question.
> whether or not it's the same *implementation* doesn't answer why ocaml
> printf choosed a different *convention* (specially on this case  
> which I
> don't see any contradiction in the way ocaml works).

I'm sorry if my reply seemed curt and unclear: I was not trying to be  
rude in my response, but only succinct.  I'll try to be clearer in  
the future.

--Jonathan

>
> Cheers,
> -- 
> Vincent Hanquez
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] precision not working properly for strings in Printf?

[Quôc Peyrot]

On Jun 27, 2007, at 10:34 AM, Vincent Hanquez wrote:

> On Wed, Jun 27, 2007 at 12:11:01AM -0400, Jonathan Bryant wrote:
>> The OCaml standard library isn't glibc.  The implementation of the
>> Printf/Scanf modules is custom, OCaml specific and tied into the
>> compiler, so one should not assume the behave the same way.  They are
>> not simply wrappers.  As a matter of fact, they have several other
>> differences from the glibc printf family of functions (look at the
>> conversion specifiers in the docs).
>>
>>> As said above, this is not how printf is working in the glibc (at
>>> least on linux and Mac OS X). Any clue why the same convention has
>>> not been followed?
>>
>> See above.
>
> What about reading before replying ?
> Your "explanation" certainly doesn't answer his question.
> whether or not it's the same *implementation* doesn't answer why ocaml
> printf choosed a different *convention* (specially on this case  
> which I
> don't see any contradiction in the way ocaml works).

Thanks for your support ;)
I was starting to wonder why I was getting such dismissive answers

-- 
Best Regards,
Quôc

Re: [Caml-list] precision not working properly for strings in Printf?

[Quôc Peyrot]

On Jun 27, 2007, at 11:53 AM, Jonathan Bryant wrote:

>> I was just expecting it to work like the printf from the glibc:
>
>>>> Any clue why the same convention has
>>>> not been followed?
>>>
>
> Apparently my implication in my first response was not clear to  
> some, so I'll clarify what I meant:
>
> The reasons for not following standard *nix conventions is a choice  
> of the language/library designer, so I cannot speak on their behalf.
>
> I'd assume, though, that since the library was implemented from  
> scratch, the conventions were not followed because it was, in some  
> cases, opportune not to follow them.  For example, some glibc  
> conventions do not work for OCaml (such as pointer conversions),  
> and the existing conventions did not handle things such as  
> polymorphic values.  In these cases, the designer simply took  
> advantage of an opportunity to "fix" printf for OCaml.  There's  
> nothing wrong with glibc's implementation, except that it's  
> designed for C.
>
> In other cases, such as the string conversion specifier, there is  
> no contradiction, so maybe it's an oversight, maybe it's for  
> consistency with numeric conversions, maybe it's easier to  
> implement that way, or maybe it's just how the designer thought it  
> should work.  In any case, that's the way the library was designed  
> and documented and it's the designer's prerogative to implement it  
> how they see fit.  The OCaml version is only based on glibc's  
> printf while being designed specifically for OCaml, probably with  
> the knowledge that String.sub is a simple function to use.

Of course I do realize that OCaml's printf is not glibc's printf, nor  
it is simply a wrapper. I did try to read the code to see if I could  
spot any comments/specific code which would explain this difference  
of behavior. It's not like I'm a complete noob who doesn't realize  
that you can't always follow every single convention/feature. But  
this module is still called "Printf", with function such as printf,  
sprintf, fprintf... So it's not like the designers didn't really try  
to follow/get inspiration from the C version either, thus I don't  
think my question is that stupid (but maybe it is...).

Sorry if I wasn't very clear, but my question was not a general "how  
can I do that" type of question, but it was a design question. To me  
it looks like an overlook, but I learned multiple times that OCaml  
can be quite subtle about what you can and can't do, and that most of  
the time, there often is a good reason why a specific feature is  
missing. And here, we are talking about Printf, which is quite subtle  
by itself anyway because of the type checking involved (for example,  
one could wonder why he cannot build format strings at runtime as in  
C. But in this case, there is a very good reason for this...)

Hence my question: is it an overlook and if not, what is the  
background behind this choice?

I don't mean to be rude either, but I would have posted in  
ocaml_beginner if I just wanted to know I could use String.sub  
instead of this feature (ExtString.String.slice is probably more  
appropriate if you don't want to deal with out of bound problems).

Thanks,

-- 
Best Regards,
Quôc

Re: [Caml-list] precision not working properly for strings in Printf?

[David Thomas]

While it is true that, theoretically, changing this to
be in line with the C libraries has the potential to
break existing code, I would stipulate that any code
that would be broken by this change is already broken.
 My reasoning is as follows.

The Printf format strings are intended to be intuitive
to anyone who has worked with printf in C.  This
deviation, therefore, means that someone reading
through code that says %.ns will reasonably but
incorrectly come to a conclusion as to what that
means.  As there is a shorter way of expressing
exactly the same thing, of greater clarity, in line
with expectations, I would be quite surprised if any
code does use %.ns to mean %ns, and I think that any
such instances should be changed for the sake of
clarity even absent any changes to the library.

I conclude that, absent strong internal reasons for
not doing so (and I have not looked at the
implementation of the library, so I cannot speak to
these), the behavior of %.ns should be declared a bug
and brought in line with the C libraries.  Failing
this, it should be a warning/error to use %.ns as
there is no motivation to do so, it is misleading when
others consider the code, and it will more quickly
inform the programmer that they cannot produce the
desired effect in this manner.


       
____________________________________________________________________________________
Pinpoint customers who are looking for what you sell. 
http://searchmarketing.yahoo.com/