Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #64771 > unrolled thread

printf format specifier changes

Back to article view | Back to comp.lang.c

Contents

  printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 09:04 -0700
    Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-06 17:50 +0100
      Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 11:34 -0700
        Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-06 19:47 +0100
          Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-06 19:53 +0100
            Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 11:57 -0700
        Re: printf format specifier changes "James Harris" <james.harris.1@gmail.com> - 2015-09-06 10:53 +0100
          Re: printf format specifier changes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-06 04:21 -0700
          Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-06 13:41 +0100
      Re: printf format specifier changes Richard Heathfield <rjh@cpax.org.uk> - 2015-07-06 19:44 +0100
        Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-06 22:14 +0100
          Re: printf format specifier changes Robert Wessel <robertwessel2@yahoo.com> - 2015-07-06 22:43 -0500
          Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-06 23:01 -0700
            Re: printf format specifier changes glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-07 06:43 +0000
            Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-09 10:52 +0300
              Re: printf format specifier changes Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 09:26 +0100
                Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-12 12:56 +0300
                  Re: printf format specifier changes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-12 06:12 -0700
          Re: printf format specifier changes Rosario19 <Ros@invalid.invalid> - 2015-07-07 10:22 +0200
            Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-07 10:10 +0100
        Re: printf format specifier changes Philip Lantz <prl@canterey.us> - 2015-07-07 00:54 -0700
      Re: printf format specifier changes Nobody <nobody@nowhere.invalid> - 2015-07-07 15:08 +0100
        Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-07 16:12 +0100
          Re: printf format specifier changes raltbos@xs4all.nl (Richard Bos) - 2015-07-09 10:34 +0000
            Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-09 12:25 +0100
              Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-12 13:02 +0300
                Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-12 11:23 +0100
      Re: printf format specifier changes <william@wilbur.25thandClement.com> - 2015-07-07 11:50 -0700
        Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-07 12:14 -0700
      Re: printf format specifier changes Les Cargill <lcargill99@comcast.com> - 2015-07-07 21:52 -0500
        Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-07 20:42 -0700
          Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-09 11:12 +0300
            Re: printf format specifier changes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-09 05:03 -0700
              Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-09 13:10 -0500
            Re: printf format specifier changes James Kuyper <jameskuyper@verizon.net> - 2015-07-09 08:58 -0400
            Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-09 08:10 -0700
              Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-12 12:58 +0300
                Re: printf format specifier changes James Kuyper <jameskuyper@verizon.net> - 2015-07-12 12:57 -0400
                Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-12 11:14 -0700
                  Re: printf format specifier changes gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-12 18:26 +0000
        Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-08 13:09 +0100
        Re: printf format specifier changes James Kuyper <jameskuyper@verizon.net> - 2015-07-08 08:10 -0400
          Re: printf format specifier changes Les Cargill <lcargill99@comcast.com> - 2015-07-08 08:12 -0500
            Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-08 08:38 -0700
            Re: printf format specifier changes James Kuyper <jameskuyper@verizon.net> - 2015-07-08 12:00 -0400
              Re: printf format specifier changes Les Cargill <lcargill99@comcast.com> - 2015-07-08 17:20 -0500
        Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-09 11:08 +0300
      Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-08 20:30 +0300
        Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-08 18:56 +0100
          Re: printf format specifier changes gordonb.lmwiv@burditt.org (Gordon Burditt) - 2015-07-09 11:09 -0500
            Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-09 14:05 -0500
        Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-08 11:27 -0700
          Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-08 15:07 -0500
    Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-06 23:39 -0500
      Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-07 10:19 +0100
        Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-07 07:57 -0500
          Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-07 14:15 +0100
            Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-07 14:46 +0100
            Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-07 09:37 -0500
          Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-09 11:24 +0300
            Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-09 09:55 -0500
              Re: printf format specifier changes <william@wilbur.25thandClement.com> - 2015-07-09 11:53 -0700
                Re: printf format specifier changes <william@wilbur.25thandClement.com> - 2015-07-09 13:48 -0700
                Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-09 17:01 -0500
      Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-07 10:59 +0100
        Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-07 07:48 -0500
          Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-07 14:30 +0100
            Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-07 10:05 -0500
              Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-07 23:16 +0100
                Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-07 20:29 -0500
                Re: printf format specifier changes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-08 00:43 -0700
                Re: printf format specifier changes Robert Wessel <robertwessel2@yahoo.com> - 2015-07-09 02:29 -0500
                  Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-09 10:34 +0100
                    Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-09 09:35 -0500
            Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-07 08:37 -0700
              Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-07 08:45 -0700
            Re: printf format specifier changes <william@wilbur.25thandClement.com> - 2015-07-07 12:12 -0700
    Re: printf format specifier changes pooja deshpande <namitadeshpande25@gmail.com> - 2015-07-09 09:29 -0700
      Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-09 09:34 -0700
        Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-09 09:59 -0700
          Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-09 22:33 +0100
            Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-09 15:17 -0700
              Re: printf format specifier changes glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-10 00:30 +0000
                Re: printf format specifier changes Reinhardt Behm <rbehm@hushmail.com> - 2015-07-10 09:17 +0800
        Re: printf format specifier changes David Kleinecke <dkleinecke@gmail.com> - 2015-07-09 10:02 -0700
          Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-09 10:19 -0700
        Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-09 21:50 +0100
          Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-09 15:05 -0700
            Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-09 15:09 -0700
            Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-10 00:28 +0100
              Re: printf format specifier changes raltbos@xs4all.nl (Richard Bos) - 2015-07-13 20:39 +0000
          Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-09 15:07 -0700
            Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-09 23:16 +0100
              Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-09 15:25 -0700

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#65012

On 7/9/2015 3:24 AM, Phil Carmody wrote:
> BGB <cr88192@hotmail.com> writes:
>> On 7/7/2015 4:19 AM, Bartc wrote:
>>> On 07/07/2015 05:39, BGB wrote:
>>>> possible additions:
>>>> ability to (optionally) specify argument numbers, rather than arguments
>>>> always being processed in-order;
>>>
>>> I think that already exists. Something like printf("%$2d %$1d",a,b) to
>>> print b first then a.
>>
>> I am not aware of such a syntax, and don't see it listed anywhere.
>
> GCC supports it as an extension. Which implies that it's actually
> glibc that supports it as an extension, and therefore that it should
> be available to any compiler linking to glibc for *printf, diagnostics
> permitting.
>

ok. I am not using glibc, but this feature can be added easily enough to 
a custom printf.


> $ man 3 printf
> ...
>         argument.  The C99 standard does not include the style using  '$',  which
>         comes  from  the  Single  Unix  Specification.  If the style using '$' is
> ...
>
> I'd like to see that bubbled into ISO C, to be honest, I find it
> extremely useful.
>

though, I guess some cases would make it difficult to support with 
conventional stdarg. my guess is you would need multiple passes:
   1st pass over the format string to figure out argument types;
   2nd pass, read the arguments in-order into an intermediate form;
   3rd pass, do the print.

this could have a problem though if some args were unused (could not 
reliably skip over them on some ABIs).


on some ABIs though, random access should be easier.
for example, the Win64 ABI has the special feature that all arguments 
are 64 bits (*).
my VM's internal ABI also has this property.

SysV/AMD64 lacks this property, as does x86 cdecl.

*: anything narrower is expanded, anything wider is passed by reference.


> Phil
>

[toc] | [prev] | [next] | [standalone]

#65061

BGB <cr88192@hotmail.com> wrote:
> On 7/9/2015 3:24 AM, Phil Carmody wrote:
<snip>
>> GCC supports it as an extension. Which implies that it's actually glibc
>> that supports it as an extension, and therefore that it should be
>> available to any compiler linking to glibc for *printf, diagnostics
>> permitting.
> 
> ok. I am not using glibc, but this feature can be added easily enough to 
> a custom printf.
> 
>> $ man 3 printf
>> ...
>>         argument.  The C99 standard does not include the style using  '$',  which
>>         comes  from  the  Single  Unix  Specification.  If the style using '$' is
>> ...
>>
>> I'd like to see that bubbled into ISO C, to be honest, I find it
>> extremely useful.
> 
> though, I guess some cases would make it difficult to support with 
> conventional stdarg. my guess is you would need multiple passes:
>   1st pass over the format string to figure out argument types;
>   2nd pass, read the arguments in-order into an intermediate form;
>   3rd pass, do the print.
> 
> this could have a problem though if some args were unused (could not 
> reliably skip over them on some ABIs).

And that's part of the POSIX specification. You can use an argument out of
order, but there must be a type specifier somewhere in the format for all
preceding arguments. So sometimes you must do crazy stuff like

	snprintf("c:%3d b:%2d\0a:%1ld", a, b, c); /* NB embedded '\0' */

The few times I've found this feature useful, I've run up against this
limitation and resorted to such hackery.

> on some ABIs though, random access should be easier.
> for example, the Win64 ABI has the special feature that all arguments 
> are 64 bits (*).

That seems eminently sensible.

[toc] | [prev] | [next] | [standalone]

#65067

william@wilbur.25thandclement.com wrote:
> BGB <cr88192@hotmail.com> wrote:
>> On 7/9/2015 3:24 AM, Phil Carmody wrote:
> <snip>
>>> GCC supports it as an extension. Which implies that it's actually glibc
>>> that supports it as an extension, and therefore that it should be
>>> available to any compiler linking to glibc for *printf, diagnostics
>>> permitting.
>> 
>> ok. I am not using glibc, but this feature can be added easily enough to 
>> a custom printf.
>> 
>>> $ man 3 printf
>>> ...
>>>         argument.  The C99 standard does not include the style using  '$',  which
>>>         comes  from  the  Single  Unix  Specification.  If the style using '$' is
>>> ...
>>>
>>> I'd like to see that bubbled into ISO C, to be honest, I find it
>>> extremely useful.
>> 
>> though, I guess some cases would make it difficult to support with 
>> conventional stdarg. my guess is you would need multiple passes:
>>   1st pass over the format string to figure out argument types;
>>   2nd pass, read the arguments in-order into an intermediate form;
>>   3rd pass, do the print.
>> 
>> this could have a problem though if some args were unused (could not 
>> reliably skip over them on some ABIs).
> 
> And that's part of the POSIX specification. You can use an argument out of
> order, but there must be a type specifier somewhere in the format for all
> preceding arguments. So sometimes you must do crazy stuff like
> 
>         snprintf("c:%3d b:%2d\0a:%1ld", a, b, c); /* NB embedded '\0' */

That should be:

	snprintf("c:%3$d b:%2$d%4$ca:%1$ld", a, b, c, '\0');

[toc] | [prev] | [next] | [standalone]

#65073

On 7/9/2015 1:53 PM, william@wilbur.25thandClement.com wrote:
> BGB <cr88192@hotmail.com> wrote:
>> On 7/9/2015 3:24 AM, Phil Carmody wrote:
> <snip>
>>> GCC supports it as an extension. Which implies that it's actually glibc
>>> that supports it as an extension, and therefore that it should be
>>> available to any compiler linking to glibc for *printf, diagnostics
>>> permitting.
>>
>> ok. I am not using glibc, but this feature can be added easily enough to
>> a custom printf.
>>
>>> $ man 3 printf
>>> ...
>>>          argument.  The C99 standard does not include the style using  '$',  which
>>>          comes  from  the  Single  Unix  Specification.  If the style using '$' is
>>> ...
>>>
>>> I'd like to see that bubbled into ISO C, to be honest, I find it
>>> extremely useful.
>>
>> though, I guess some cases would make it difficult to support with
>> conventional stdarg. my guess is you would need multiple passes:
>>    1st pass over the format string to figure out argument types;
>>    2nd pass, read the arguments in-order into an intermediate form;
>>    3rd pass, do the print.
>>
>> this could have a problem though if some args were unused (could not
>> reliably skip over them on some ABIs).
>
> And that's part of the POSIX specification. You can use an argument out of
> order, but there must be a type specifier somewhere in the format for all
> preceding arguments. So sometimes you must do crazy stuff like
>
> 	snprintf("c:%3d b:%2d\0a:%1ld", a, b, c); /* NB embedded '\0' */
>
> The few times I've found this feature useful, I've run up against this
> limitation and resorted to such hackery.
>

ok, makes sense.

although, I wouldn't think printf would be able to see past the '\0' either.


>> on some ABIs though, random access should be easier.
>> for example, the Win64 ABI has the special feature that all arguments
>> are 64 bits (*).
>
> That seems eminently sensible.
>

yeah.

Win64 and SysV/AMD64 went in different directions:
Win64 is mostly fairly straightforward to support from compilers and 
tools (with some funkiness);
SysV/AMD64 is a bit into trying to micro-optimize edge cases (but, apart 
from the complex edge cases, is mostly ok).


FWIW, one can ignore the edge cases and everything still basically works 
ok (because the edge cases are pretty rare, at least in my experience).

[toc] | [prev] | [next] | [standalone]

#64843

BGB <cr88192@hotmail.com> writes:

> On 7/6/2015 11:04 AM, Rick C. Hodgin wrote:
>> In 2015, what suggestions would you have for changing anything about
>> the format specifiers used in the printf functions?
<snip>
> possible additions:
<snip>
> more "good" options for things like formatting float numbers (*2);
> ...
<snip>

> *2: possible examples:
> left-justified numbers padded to the right with spaces;

Isn't that possible now?  Can you give an example of what you mean if
it's not what "%-9.3f" currently does?

> space-padded center-aligned numbers on both the left and right;

Yes, that might be useful every now and then, but I don't recall any
cases of wanting it.

> ability for numbers to have a variable number of digits following the
> decimal point;

Do you mean like an automatic version of "%10.*f"?  How would the number
of digits be determined?

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#64847

On 7/7/2015 4:59 AM, Ben Bacarisse wrote:
> BGB <cr88192@hotmail.com> writes:
>
>> On 7/6/2015 11:04 AM, Rick C. Hodgin wrote:
>>> In 2015, what suggestions would you have for changing anything about
>>> the format specifiers used in the printf functions?
> <snip>
>> possible additions:
> <snip>
>> more "good" options for things like formatting float numbers (*2);
>> ...
> <snip>
>
>> *2: possible examples:
>> left-justified numbers padded to the right with spaces;
>
> Isn't that possible now?  Can you give an example of what you mean if
> it's not what "%-9.3f" currently does?
>

for whatever reason, I was not aware of '-' working with numbers 
(thought it was a string specific feature for some reason).


then again, my memory also includes "%lld" not working on MSVC (with 
"%I64d" needed instead), though it should work according to the 
documentation.


>> space-padded center-aligned numbers on both the left and right;
>
> Yes, that might be useful every now and then, but I don't recall any
> cases of wanting it.
>

yeah.


>> ability for numbers to have a variable number of digits following the
>> decimal point;
>
> Do you mean like an automatic version of "%10.*f"?  How would the number
> of digits be determined?
>

I meant more like:
   2
   3.14159
   6.995
   ...

where if the digits after a given point are all 0s, they are omitted.

sort of like what '%g' theoretically does, just without falling back to 
'%e' mode.


usual partial solution is a function which prints using '%f' and trims 
off rightward 0's (and the decimal point, if needed), then printing a 
temporary string.


AFAIK, '*' isn't supported by MSVC.
then again, asking for anything much beyond C89 is asking a bit much of 
MSVC...

[toc] | [prev] | [next] | [standalone]

#64852

BGB <cr88192@hotmail.com> writes:

> On 7/7/2015 4:59 AM, Ben Bacarisse wrote:
>> BGB <cr88192@hotmail.com> writes:
>>
>>> On 7/6/2015 11:04 AM, Rick C. Hodgin wrote:
>>>> In 2015, what suggestions would you have for changing anything about
>>>> the format specifiers used in the printf functions?
>> <snip>
>>> possible additions:
<snip>
>>> ability for numbers to have a variable number of digits following the
>>> decimal point;
>>
>> Do you mean like an automatic version of "%10.*f"?  How would the number
>> of digits be determined?
>
> I meant more like:
>   2
>   3.14159
>   6.995
>   ...
>
> where if the digits after a given point are all 0s, they are omitted.

I see.  I think it would need to be pinned down a bit more because only
two of your three examples can be represented in binary float point --
i.e. the floating point numbers closest to 3.14159000... and
6.995000... both have non-zero decimal digits eventually.  In other
words I'd want some sort of decimal rounding followed by removal of
trailing zeros, but that comes for free as the precision.  I.e. using R
as the format, double x = 6.9950000021000

  printf("%.0R",  x); // output: "7"     (same as with "%.0f")
  printf("%.3R",  x); // output: "6.995" (same as with "%.3f")
  printf("%.8R",  x); // output: "6.995"
  printf("%.9R",  x); // output: "6.995000002"
  printf("%.15R", x); // output: "6.9950000021"

<snip>
> AFAIK, '*' isn't supported by MSVC.

Unlikely, but I don't think I've ever used MSVC.
 
> then again, asking for anything much beyond C89 is asking a bit much
> of MSVC...

The use of * as a width ("%*d"), as a precision "(%6.*f") or as both
("%*.*f"), are in the old ANSI C (C89/90 whatever name you like).

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#64859

On 7/7/2015 8:30 AM, Ben Bacarisse wrote:
> BGB <cr88192@hotmail.com> writes:
>
>> On 7/7/2015 4:59 AM, Ben Bacarisse wrote:
>>> BGB <cr88192@hotmail.com> writes:
>>>
>>>> On 7/6/2015 11:04 AM, Rick C. Hodgin wrote:
>>>>> In 2015, what suggestions would you have for changing anything about
>>>>> the format specifiers used in the printf functions?
>>> <snip>
>>>> possible additions:
> <snip>
>>>> ability for numbers to have a variable number of digits following the
>>>> decimal point;
>>>
>>> Do you mean like an automatic version of "%10.*f"?  How would the number
>>> of digits be determined?
>>
>> I meant more like:
>>    2
>>    3.14159
>>    6.995
>>    ...
>>
>> where if the digits after a given point are all 0s, they are omitted.
>
> I see.  I think it would need to be pinned down a bit more because only
> two of your three examples can be represented in binary float point --
> i.e. the floating point numbers closest to 3.14159000... and
> 6.995000... both have non-zero decimal digits eventually.  In other
> words I'd want some sort of decimal rounding followed by removal of
> trailing zeros, but that comes for free as the precision.  I.e. using R
> as the format, double x = 6.9950000021000
>
>    printf("%.0R",  x); // output: "7"     (same as with "%.0f")
>    printf("%.3R",  x); // output: "6.995" (same as with "%.3f")
>    printf("%.8R",  x); // output: "6.995"
>    printf("%.9R",  x); // output: "6.995000002"
>    printf("%.15R", x); // output: "6.9950000021"
>

yeah, I had figured with some way to limit the maximum number of 
fractional digits.


> <snip>
>> AFAIK, '*' isn't supported by MSVC.
>
> Unlikely, but I don't think I've ever used MSVC.
>

MSVC is the main compiler I am using for Windows-side development.


looking into it: apparently it is supported in most newish versions 
(apparently pretty much all them for about the past decade). good to 
know I guess...


>> then again, asking for anything much beyond C89 is asking a bit much
>> of MSVC...
>
> The use of * as a width ("%*d"), as a precision "(%6.*f") or as both
> ("%*.*f"), are in the old ANSI C (C89/90 whatever name you like).
>

ok.

had thought it was newer.


looked it up, turns out that support for '%lld' and similar in MSVC 
depends on version, with older versions lacking it, but most newer 
versions supporting it.

looking into it, it seems '*' is in the same general boat as 'll' 
(support got added but I didn't notice it).


but, I guess they are moving along in any case, for example, having 
added 'stdint.h' support in VS2013.

[toc] | [prev] | [next] | [standalone]

#64881

BGB <cr88192@hotmail.com> writes:

> On 7/7/2015 8:30 AM, Ben Bacarisse wrote:
>> BGB <cr88192@hotmail.com> writes:
<snip>
>>> AFAIK, '*' isn't supported by MSVC.
>>
>> Unlikely, but I don't think I've ever used MSVC.
>
> MSVC is the main compiler I am using for Windows-side development.
>
> looking into it: apparently it is supported in most newish versions
> (apparently pretty much all them for about the past decade). good to
> know I guess...

So are you saying that MS's C library did not have a printf that
conforms to even the original ANSI C standard until about 2005?  I find
that odd but, as I say, I have no data.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#64887

On 7/7/2015 5:16 PM, Ben Bacarisse wrote:
> BGB <cr88192@hotmail.com> writes:
>
>> On 7/7/2015 8:30 AM, Ben Bacarisse wrote:
>>> BGB <cr88192@hotmail.com> writes:
> <snip>
>>>> AFAIK, '*' isn't supported by MSVC.
>>>
>>> Unlikely, but I don't think I've ever used MSVC.
>>
>> MSVC is the main compiler I am using for Windows-side development.
>>
>> looking into it: apparently it is supported in most newish versions
>> (apparently pretty much all them for about the past decade). good to
>> know I guess...
>
> So are you saying that MS's C library did not have a printf that
> conforms to even the original ANSI C standard until about 2005?  I find
> that odd but, as I say, I have no data.
>

I could be wrong, FWIW. from what I can tell it goes back about as far 
as V2003, which does cover (more or less) everything for about the past 
decade.

some info elsewhere says some holes in C89 support were patched up for 
sake of C++03 conformance in VS2003.


support for the 'll' modifier appears to go back to VS2005, so right 
about 10 years there.


though, FWIW, it was only in VS2013 that they went and added a lot of 
C99 features. apparently, this was partly motivated because a lot of 
parts from C99 were added to C++11.

apparently they also went and addressed enough C99 conformance issues to 
get ffmpeg to compile from source (apparently making 'tactical' choices 
as to where to invest implementation effort).


but, as an implementation, it is pretty slow-moving sometimes...

[toc] | [prev] | [next] | [standalone]

#64897

On Tuesday, July 7, 2015 at 11:16:12 PM UTC+1, Ben Bacarisse wrote:
> 
> So are you saying that MS's C library did not have a printf that
> conforms to even the original ANSI C standard until about 2005?  I find
> that odd but, as I say, I have no data.
> 
I suspect he's mixing up the wide character version of the function.

That's badly crippled. It won't even print floats, on the basis, I
suppose, that in some strange parts they use a comma as a decimal
point.

[toc] | [prev] | [next] | [standalone]

#64967

On Tue, 07 Jul 2015 23:16:03 +0100, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

>BGB <cr88192@hotmail.com> writes:
>
>> On 7/7/2015 8:30 AM, Ben Bacarisse wrote:
>>> BGB <cr88192@hotmail.com> writes:
><snip>
>>>> AFAIK, '*' isn't supported by MSVC.
>>>
>>> Unlikely, but I don't think I've ever used MSVC.
>>
>> MSVC is the main compiler I am using for Windows-side development.
>>
>> looking into it: apparently it is supported in most newish versions
>> (apparently pretty much all them for about the past decade). good to
>> know I guess...
>
>So are you saying that MS's C library did not have a printf that
>conforms to even the original ANSI C standard until about 2005?  I find
>that odd but, as I say, I have no data.


Now I didn't spend too much time comparing the definitions to those in
the standard, but my hardcopy MSC 5.0 manuals specify that printf
format strings can use an * for width and precision.  Circa 1987.

[toc] | [prev] | [next] | [standalone]

#64976

Robert Wessel <robertwessel2@yahoo.com> writes:

> On Tue, 07 Jul 2015 23:16:03 +0100, Ben Bacarisse
> <ben.usenet@bsb.me.uk> wrote:
>
>>BGB <cr88192@hotmail.com> writes:
>>
>>> On 7/7/2015 8:30 AM, Ben Bacarisse wrote:
>>>> BGB <cr88192@hotmail.com> writes:
>><snip>
>>>>> AFAIK, '*' isn't supported by MSVC.
>>>>
>>>> Unlikely, but I don't think I've ever used MSVC.
>>>
>>> MSVC is the main compiler I am using for Windows-side development.
>>>
>>> looking into it: apparently it is supported in most newish versions
>>> (apparently pretty much all them for about the past decade). good to
>>> know I guess...
>>
>>So are you saying that MS's C library did not have a printf that
>>conforms to even the original ANSI C standard until about 2005?  I find
>>that odd but, as I say, I have no data.
>
>
> Now I didn't spend too much time comparing the definitions to those in
> the standard, but my hardcopy MSC 5.0 manuals specify that printf
> format strings can use an * for width and precision.  Circa 1987.

Thanks for looking.  That's much more what I expected.  I got the
feeling that * was pretty much universal by the time it was
standardised.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#65010

On 7/9/2015 4:34 AM, Ben Bacarisse wrote:
> Robert Wessel <robertwessel2@yahoo.com> writes:
>
>> On Tue, 07 Jul 2015 23:16:03 +0100, Ben Bacarisse
>> <ben.usenet@bsb.me.uk> wrote:
>>
>>> BGB <cr88192@hotmail.com> writes:
>>>
>>>> On 7/7/2015 8:30 AM, Ben Bacarisse wrote:
>>>>> BGB <cr88192@hotmail.com> writes:
>>> <snip>
>>>>>> AFAIK, '*' isn't supported by MSVC.
>>>>>
>>>>> Unlikely, but I don't think I've ever used MSVC.
>>>>
>>>> MSVC is the main compiler I am using for Windows-side development.
>>>>
>>>> looking into it: apparently it is supported in most newish versions
>>>> (apparently pretty much all them for about the past decade). good to
>>>> know I guess...
>>>
>>> So are you saying that MS's C library did not have a printf that
>>> conforms to even the original ANSI C standard until about 2005?  I find
>>> that odd but, as I say, I have no data.
>>
>>
>> Now I didn't spend too much time comparing the definitions to those in
>> the standard, but my hardcopy MSC 5.0 manuals specify that printf
>> format strings can use an * for width and precision.  Circa 1987.
>
> Thanks for looking.  That's much more what I expected.  I got the
> feeling that * was pretty much universal by the time it was
> standardised.
>

ok, I was wrong about it then...

[toc] | [prev] | [next] | [standalone]

#64863

ram@zedat.fu-berlin.de (Stefan Ram) writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>AFAIK, '*' isn't supported by MSVC.
>>Unlikely, but I don't think I've ever used MSVC.
>
> There is something about C implementations that I
> learned relatively recently.
>
> I used to think that a Windows C compiler had its C library.
> But no, they (MinGW/gcc) seem to take pride in using the
> C library of the operating system!

MinGW is a C implementation that uses gcc as the compiler component and
Microsoft's C library as the library component.  I'm not aware that the
providers of MinGW "take pride" in this.  I think it just happens to be
a lot easier to use an existing runtime library than to write your own.

> On Windows, this seems to be
>
> MSVCRT.DLL
>
> . So, when one would complain to MinGW that printf does not
> support formats such as »%zu«¹, they would respond: Don't
> complain to us, we are just passing this trough to the
> operating system!² They seem to assume that C programmers
> on Windows want it this way.³ But when I choose C, I 
> personally mean ISO/IEC 9899:2011, and this /has/ »%zu«¹.

The lack of support for "%zu" is clearly a problem, and is the
result of using a runtime library that only supports C90 (with some
Microsoft extensions).  The inconsistency between the compiler and
the library in the size of long double is IMHO a bigger problem
with MinGW.  If I recall correctly, gcc makes long double wider
than double, but the Microsoft runtime library makes them the same
size; as a result, printing a long double value using printf under
MinGW fails.

> Recently, there seems to be a Windows compiler called »TDM«
> (based on MinGW and gcc?) and compile-time flags like
> -D__USE_MINGW_ANSI_STDIO=1 and some changes that might help
> programmers to get better support for C features.

As the name implies, -D__USE_MINGW_ANSI_STDIO=1 is supported by MinGW,
not just by TDM.

>                                                   However,
> when something is advertised as a »C compiler«, I prefer
> it to behave as a C compiler by default and only need options
> to use the non-conformant operating-system library.

I agree -- but I don't know of *any* C implementation that's conforming
by default.

It shouldn't be difficult to write a wrapper that invokes
it with any necessary options.

> 1) Disclaimer: I am not sure whether I remember this
> specific example correctly.
>
> 2) Disclaimer: I made this up, the actual response might
> differ.
>
> 3) I.e., be able to compile code written for Microsoft®
> compilers to be compiled with as few changes as possible

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#64865

On Tuesday, July 7, 2015 at 11:37:48 AM UTC-4, Keith Thompson wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
> > Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> >>>AFAIK, '*' isn't supported by MSVC.
> >>Unlikely, but I don't think I've ever used MSVC.
> >
> > There is something about C implementations that I
> > learned relatively recently.
> >
> > I used to think that a Windows C compiler had its C library.
> > But no, they (MinGW/gcc) seem to take pride in using the
> > C library of the operating system!
> 
> MinGW is a C implementation that uses gcc as the compiler component and
> Microsoft's C library as the library component.  I'm not aware that the
> providers of MinGW "take pride" in this.  I think it just happens to be
> a lot easier to use an existing runtime library than to write your own.

MinGW uses more than Windows libraries.  It comes with many of its
own (which seem to have come directly from something GCC-related).
There are at least two MinGW-specific DLLs which are required for
any MinGW-compiled .exe to run in Windows when compiled with g++,
which I assume are wrappers from GCC-conventions into Windows
conventions):

    libgcc_s_dw2-1.dll   110 KB
    libstdc++-6.dll      978 KB

On the whole, I've found MinGW code to be slightly faster than
the code generated by VS2008 and VS2010.  I have not been able
to get 64-bit MinGW GCC-compiled code to run in Windows on my
Visual FreePro, Jr. application.  It compiles and runs in 32-bit
mode.  It compiles without error in 64-bit mode.  But it crashes
on startup before it reaches the first source line of my main()
function.  I have not spent time investigating why because the
64-bit version I compile in VS2010 does work properly.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#64870

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>AFAIK, '*' isn't supported by MSVC.
>>Unlikely, but I don't think I've ever used MSVC.
> 
>   There is something about C implementations that I
>   learned relatively recently.
> 
>   I used to think that a Windows C compiler had its C library.
>   But no, they (MinGW/gcc) seem to take pride in using the
>   C library of the operating system!
> 
>   On Windows, this seems to be
> 
> MSVCRT.DLL

Conversely, each version of Visual Studio ships it's own CRT, which up until
the most recent was backwards and forwards incompatible, and incompatible
with the "system" CRT. I gather that this is one of the biggest reasons for
DLL hell on Windows, and why it's so common to ship seemingly duplicate
libraries. (They're not really duplicate because they depend on the
particular CRT version used by that application.)

I think this is still technically an issue with even the latest version of
Visual Studio, but now they're actually committed to mitigating the most
egregious issues (such as with malloc/free) going forward.

FWIW, here's an interesting project which brings a "native" POSIX
environment to Windows: http://midipix.org/. They implement some primtives,
like open and poll, as wrappers around Window's native interfaces (or
otherwise hook into the Window's subsystem to make the integration
effectively native). So, for example, a POSIX file descriptor is a valid
Windows file descriptor.

Then they've ported musl-libc (an excellent POSIX-compliant libc that I hope
will soon displace glibc) to provide the remainder of the API. The upshot is
that you can mix-and-match libraries using the POSIX API with libraries
using the native API, and with some limitations the native API is still
available to the POSIX-targeted units.

They also claim to have implemented a copy-on-write fork with descriptor
inheritance, etc, and in a manner that doesn't break Windows-native code.

[toc] | [prev] | [next] | [standalone]

#65024

On Monday, July 6, 2015 at 9:34:47 PM UTC+5:30, Rick C. Hodgin wrote:
> In 2015, what suggestions would you have for changing anything about
> the format specifiers used in the printf functions?  Leave them as
> they are?  Or change this or that about them?
> 
> Best regards,
> Rick C. Hodgin
hoping for no changes!!

[toc] | [prev] | [next] | [standalone]

#65026

On Thursday, July 9, 2015 at 12:29:55 PM UTC-4, pooja deshpande wrote:
> On Monday, July 6, 2015 at 9:34:47 PM UTC+5:30, Rick C. Hodgin wrote:
> > In 2015, what suggestions would you have for changing anything about
> > the format specifiers used in the printf functions?  Leave them as
> > they are?  Or change this or that about them?
> > 
> hoping for no changes!!

The only real change I would like to see is a memprintf() function
which does not automatically add a trailing null, but otherwise
behave like sprintf() functions.  And one more:  I would like to
see the format specifiers moved to their variable instance, like
this:

Old way:
    printf("%s %p\n", ptr, ptr);

New way:
    printf("% %\n", [s]ptr, [p]ptr);

I think putting the specifiers by their variables would lend itself
to easier understanding and maintenance in code:

    printf("% %\n",   [s]  ptr,   // Show content
                      [p]  ptr);  // Show address of content

The eye can identify all of that.  And in this example it's not a
big deal, but when there are more types, or they are more complex,
then it will associate each.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#65031

On Thursday, July 9, 2015 at 12:34:42 PM UTC-4, Rick C. Hodgin wrote:
> On Thursday, July 9, 2015 at 12:29:55 PM UTC-4, pooja deshpande wrote:
> > On Monday, July 6, 2015 at 9:34:47 PM UTC+5:30, Rick C. Hodgin wrote:
> > > In 2015, what suggestions would you have for changing anything about
> > > the format specifiers used in the printf functions?  Leave them as
> > > they are?  Or change this or that about them?
> > > 
> > hoping for no changes!!
> 
> The only real change I would like to see is a memprintf() function
> which does not automatically add a trailing null, but otherwise
> behave like sprintf() functions.  And one more:  I would like to
> see the format specifiers moved to their variable instance, like
> this:
> 
> Old way:
>     printf("%s %p\n", ptr, ptr);
> 
> New way:
>     printf("% %\n", [s]ptr, [p]ptr);
> 
> I think putting the specifiers by their variables would lend itself
> to easier understanding and maintenance in code:
> 
>     printf("% %\n",   [s]  ptr,   // Show content
>                       [p]  ptr);  // Show address of content
> 
> The eye can identify all of that.  And in this example it's not a
> big deal, but when there are more types, or they are more complex,
> then it will associate each.

One other addition:  The ability to leave the specifier off if it
follows its natural type:

    int i = 5;
    printf("i: %\n", i);

It should not be necessary to specify the [d] part, as in:
    printf("i: %\n", [d]i);

...because in this example, i follows its natural type, which means
the compiler could deduce that the type for an int is d, and then
auto-inject its format specifier into the format specifier string
where appropriate.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web