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

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

sprintf and the trailing null

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

Contents

  sprintf and the trailing null "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 06:16 -0700
    Re: sprintf and the trailing null John McCue <jmccue@jmcnet1.bstnma.east.verizon.net> - 2015-07-06 13:30 +0000
      Re: sprintf and the trailing null "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 06:37 -0700
        Re: sprintf and the trailing null Reinhardt Behm <rbehm@hushmail.com> - 2015-07-06 21:58 +0800
          Re: sprintf and the trailing null "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 07:12 -0700
            Re: sprintf and the trailing null Reinhardt Behm <rbehm@hushmail.com> - 2015-07-06 22:34 +0800
              Re: sprintf and the trailing null "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 08:44 -0700
            Re: sprintf and the trailing null Bartc <bc@freeuk.com> - 2015-07-06 15:46 +0100
              Re: sprintf and the trailing null Keith Thompson <kst-u@mib.org> - 2015-07-06 08:06 -0700
                Re: sprintf and the trailing null Bartc <bc@freeuk.com> - 2015-07-06 17:42 +0100
                  Re: sprintf and the trailing null "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 09:48 -0700
                  Re: sprintf and the trailing null Bartc <bc@freeuk.com> - 2015-07-06 18:07 +0100
                    Re: sprintf and the trailing null Martin Shobe <martin.shobe@yahoo.com> - 2015-07-06 12:40 -0500
                  Re: sprintf and the trailing null Keith Thompson <kst-u@mib.org> - 2015-07-06 10:46 -0700
                    Re: sprintf and the trailing null Bartc <bc@freeuk.com> - 2015-07-06 18:58 +0100
            Re: sprintf and the trailing null Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-06 16:38 +0100
              Re: sprintf and the trailing null Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-06 23:44 +0100
                Re: sprintf and the trailing null "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 15:48 -0700
                Re: sprintf and the trailing null Phil Carmody <pc+usenet@asdf.org> - 2015-07-08 20:09 +0300
                  Re: sprintf and the trailing null "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-08 10:11 -0700
                    Re: sprintf and the trailing null Bartc <bc@freeuk.com> - 2015-07-08 19:01 +0100
                      Re: sprintf and the trailing null David Kleinecke <dkleinecke@gmail.com> - 2015-07-09 09:02 -0700
                        Re: sprintf and the trailing null Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 17:07 +0100
                          Re: sprintf and the trailing null Phil Carmody <pc+usenet@asdf.org> - 2015-07-10 17:06 +0300
                        Re: sprintf and the trailing null glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-09 17:42 +0000
                      Re: sprintf and the trailing null Phil Carmody <pc+usenet@asdf.org> - 2015-07-10 13:33 +0300
                        Re: sprintf and the trailing null Bartc <bc@freeuk.com> - 2015-07-10 12:09 +0100
                          Re: sprintf and the trailing null Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-10 04:51 -0700
                            Re: sprintf and the trailing null Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-10 17:24 +0100
                          Re: sprintf and the trailing null Keith Thompson <kst-u@mib.org> - 2015-07-10 08:33 -0700
                  Re: sprintf and the trailing null Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 04:58 -0700
        Re: sprintf and the trailing null jt@toerring.de (Jens Thoms Toerring) - 2015-07-06 14:15 +0000
          Re: sprintf and the trailing null "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 07:20 -0700
            Re: sprintf and the trailing null raltbos@xs4all.nl (Richard Bos) - 2015-07-06 19:54 +0000
              Re: sprintf and the trailing null "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 13:31 -0700
                Re: sprintf and the trailing null Richard Heathfield <rjh@cpax.org.uk> - 2015-07-06 21:52 +0100
                Re: sprintf and the trailing null raltbos@xs4all.nl (Richard Bos) - 2015-07-06 22:52 +0000
                  Re: sprintf and the trailing null Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-07 01:04 +0100
                  Re: sprintf and the trailing null Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-06 19:13 -0700
                    Re: sprintf and the trailing null Reinhardt Behm <rbehm@hushmail.com> - 2015-07-07 12:45 +0800
                      Re: sprintf and the trailing null Rosario19 <Ros@invalid.invalid> - 2015-07-07 10:15 +0200
                    Re: sprintf and the trailing null Bartc <bc@freeuk.com> - 2015-07-07 10:31 +0100
                      Re: sprintf and the trailing null Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-07 02:51 -0700
                        Re: sprintf and the trailing null Bartc <bc@freeuk.com> - 2015-07-07 12:10 +0100
                          Re: sprintf and the trailing null Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-07 05:08 -0700
                            Re: sprintf and the trailing null Bartc <bc@freeuk.com> - 2015-07-07 13:52 +0100
                              Re: sprintf and the trailing null Phil Carmody <pc+usenet@asdf.org> - 2015-07-08 20:20 +0300
                                Re: sprintf and the trailing null Bartc <bc@freeuk.com> - 2015-07-08 18:51 +0100
                                Re: sprintf and the trailing null raltbos@xs4all.nl (Richard Bos) - 2015-07-09 10:27 +0000
                            Re: sprintf and the trailing null Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 19:03 -0700
                Re: sprintf and the trailing null gordonb.7tw58@burditt.org (Gordon Burditt) - 2015-07-07 15:40 -0500
                  Re: sprintf and the trailing null "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-07 15:14 -0700
          Re: sprintf and the trailing null "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 07:27 -0700
            Re: sprintf and the trailing null jt@toerring.de (Jens Thoms Toerring) - 2015-07-06 16:46 +0000
          Re: sprintf and the trailing null Keith Thompson <kst-u@mib.org> - 2015-07-06 07:56 -0700
    Re: sprintf and the trailing null Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-07-06 09:32 -0600
    Re: sprintf and the trailing null Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-06 08:37 -0700
      Re: sprintf and the trailing null Keith Thompson <kst-u@mib.org> - 2015-07-06 08:54 -0700
    Re: sprintf and the trailing null "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 08:53 -0700
      Re: sprintf and the trailing null "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 09:00 -0700
      Re: sprintf and the trailing null Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-06 17:14 +0100
        Re: sprintf and the trailing null "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 09:24 -0700
          Re: sprintf and the trailing null "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 09:31 -0700
    Re: sprintf and the trailing null Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2015-07-07 01:43 +0200
      Re: sprintf and the trailing null "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 17:09 -0700
        Re: sprintf and the trailing null Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-07-06 21:08 -0600
          Re: sprintf and the trailing null "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 21:29 -0700
          Re: sprintf and the trailing null Phil Carmody <pc+usenet@asdf.org> - 2015-07-08 20:24 +0300
            Re: sprintf and the trailing null "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-08 10:44 -0700
    Re: sprintf and the trailing null Les Cargill <lcargill99@comcast.com> - 2015-07-07 21:48 -0500

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

#64949

On 08/07/2015 18:11, Rick C. Hodgin wrote:
> On Wednesday, July 8, 2015 at 1:10:00 PM UTC-4, Phil Carmody wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

>>> You could implement what you want as an extension.  Since a trailing %
>>> in the format is undefined behaviour, you could have a version of
>>> sprintf that interprets such an invalid conversion specifier as a
>>> request to omit the trailing null character.
>>
>> That is an exceptionally elegant way to solve the problem.
>
> I couldn't agree more.  I've spent several brief few-minute sessions
> thinking about this since it was posted.  It's beautiful.  Almost as
> if those original designers were looking to this future need. :-)

A couple of problems with it. First, someone has to implement it (update 
the library routines for the printf family). (Or somehow write wrappers 
around the existing printf routines, which might mean generating the 
zero then getting rid of it, not exactly efficient.)

But a % at the of a string should be an error. If it now becomes an 
acceptable format-specifier by itself, and /causes the trailing null to 
be suppressed/, it can cause programs to crash if someone intended "%d" 
but the "d" got missed out.

I think the idea to use %!, or any other accompanying code, is better.

-- 
Bartc

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

#65017

On Wednesday, July 8, 2015 at 11:02:05 AM UTC-7, Bart wrote:
> On 08/07/2015 18:11, Rick C. Hodgin wrote:
> > On Wednesday, July 8, 2015 at 1:10:00 PM UTC-4, Phil Carmody wrote:
> >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> 
> >>> You could implement what you want as an extension.  Since a trailing %
> >>> in the format is undefined behaviour, you could have a version of
> >>> sprintf that interprets such an invalid conversion specifier as a
> >>> request to omit the trailing null character.
> >>
> >> That is an exceptionally elegant way to solve the problem.
> >
> > I couldn't agree more.  I've spent several brief few-minute sessions
> > thinking about this since it was posted.  It's beautiful.  Almost as
> > if those original designers were looking to this future need. :-)
> 
> A couple of problems with it. First, someone has to implement it (update 
> the library routines for the printf family). (Or somehow write wrappers 
> around the existing printf routines, which might mean generating the 
> zero then getting rid of it, not exactly efficient.)
> 
> But a % at the of a string should be an error. If it now becomes an 
> acceptable format-specifier by itself, and /causes the trailing null to 
> be suppressed/, it can cause programs to crash if someone intended "%d" 
> but the "d" got missed out.
> 
> I think the idea to use %!, or any other accompanying code, is better.
 
Not that I much care about the % but I wonder what the best way
would really be. Wouldn't a warning when a trailing % was used be
enough? Like the warnings we get when '=' is used in a condiitonal.

I suppose the danger here is the "boy who called wolf" syndrome - if
we issue too many warnings none will be read. Personally I incline
to always expect the warnings to be read. But ...

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

#65019

On 09/07/15 17:02, David Kleinecke wrote:
> On Wednesday, July 8, 2015 at 11:02:05 AM UTC-7, Bart wrote:

<omitting the null terminating character from *printf output>

>> I think the idea to use %!, or any other accompanying code, is better.
>
> Not that I much care about the % but I wonder what the best way
> would really be.

The best way would be not to do it at all.

The *printf functions are generally used either for writing to a text 
stream (in which case the null character isn't written anyway) or to a 
string (in which case the null character is required, because otherwise 
it isn't a string).

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#65110

Richard Heathfield <rjh@cpax.org.uk> writes:
> On 09/07/15 17:02, David Kleinecke wrote:
> > On Wednesday, July 8, 2015 at 11:02:05 AM UTC-7, Bart wrote:
> 
> <omitting the null terminating character from *printf output>
> 
> >> I think the idea to use %!, or any other accompanying code, is better.
> >
> > Not that I much care about the % but I wonder what the best way
> > would really be.
> 
> The best way would be not to do it at all.
> 
> The *printf functions are generally used either for writing to a text
> stream (in which case the null character isn't written anyway) or to a
> string (in which case the null character is required, because
> otherwise it isn't a string).

Many of the str* functions do not require actual strings as their
parameters, merely (pointers to (first elements of)) arrays.
strncpy is the most obvious example, but I know that's a bit of
an embarassment to some as an outsider. Look for "array" in the
descriptions of the str* funcs.

But also look at the punchy 1-sentence summary of the behaviour
of sprintf before holding too firm to your assersions:
"""
The sprintf function is equivalent to fprintf, except that the output
is written into an array (speci#ed by the argument s) rather than to a
stream.
"""
fprintf outputs data, not strings. The destination is merely an array
not a "string" (as per the destination of strncpy). Mention of null
termination is secondary (the following sentence). One could implement
the trailing-% tweak without changing that initial sentence. OK, you'd
have to tweak the second one. but I believe in the inverted pyramid.

Phil
-- 
A well regulated militia, being necessary to the security of a free state,
the right of the people to keep and bear arms, shall be well regulated.

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

#65037

David Kleinecke <dkleinecke@gmail.com> wrote:

(snip, someone wrote)
>> I think the idea to use %!, or any other accompanying code, is better.
 
> Not that I much care about the % but I wonder what the best way
> would really be. Wouldn't a warning when a trailing % was used be
> enough? Like the warnings we get when '=' is used in a condiitonal.

By the way, %! reminds me, has anyone else noticed that HP printers
won't print files that start with %.

Postscript printers are supposed to recognize %! at the beginning,
but HP seems to have taken that down to just %. It then ignores
the rest of the file.

-- glen

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

#65098

Bartc <bc@freeuk.com> writes:
> On 08/07/2015 18:11, Rick C. Hodgin wrote:
> > On Wednesday, July 8, 2015 at 1:10:00 PM UTC-4, Phil Carmody wrote:
> >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> 
> >>> You could implement what you want as an extension.  Since a trailing %
> >>> in the format is undefined behaviour, you could have a version of
> >>> sprintf that interprets such an invalid conversion specifier as a
> >>> request to omit the trailing null character.
> >>
> >> That is an exceptionally elegant way to solve the problem.
> >
> > I couldn't agree more.  I've spent several brief few-minute sessions
> > thinking about this since it was posted.  It's beautiful.  Almost as
> > if those original designers were looking to this future need. :-)
> 
> A couple of problems with it. First, someone has to implement it
> (update the library routines for the printf family). (Or somehow write
> wrappers around the existing printf routines, which might mean
> generating the zero then getting rid of it, not exactly efficient.)
> 
> But a % at the of a string should be an error.

Says who? If you, on what authority? If the C standard, chapter
and verse, please?

> If it now becomes an
> acceptable format-specifier by itself, and /causes the trailing null
> to be suppressed/, it can cause programs to crash if someone intended
> "%d" but the "d" got missed out.

Crashing was one of the available behaviours for such code anyway.
And crashing is usualy far better than silently propagating inappropriate
values around.

> I think the idea to use %!, or any other accompanying code, is better.

On this, your opinion has as much right to be voiced as anyone else's,
of course.

Phil
-- 
A well regulated militia, being necessary to the security of a free state,
the right of the people to keep and bear arms, shall be well regulated.

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

#65100

On 10/07/2015 11:33, Phil Carmody wrote:
> Bartc <bc@freeuk.com> writes:

>> But a % at the of a string should be an error.
>
> Says who? If you, on what authority? If the C standard, chapter
> and verse, please?

7.20.6.1p9 says the behaviour is undefined.

But whatever that says, under the current rules, a sole "%" at the end 
of format string produces no output and serves no purpose.

In your opinion however, you would be quite happy to see that in code, 
and would not question it? The possibility would never occur to you that 
perhaps it's a mistake, and that a format code is missing or it's just 
an extraneous character?

The problem is that under the new proposal, you can't distinguish such 
an erroneous use from a legitimate one.

>> If it now becomes an
>> acceptable format-specifier by itself, and /causes the trailing null
>> to be suppressed/, it can cause programs to crash if someone intended
>> "%d" but the "d" got missed out.
>
> Crashing was one of the available behaviours for such code anyway.
> And crashing is usualy far better than silently propagating inappropriate
> values around.

Under the new proposed behaviour, any string created by sprintf would 
not have terminating null if "%" was at the end of the format string.

This could give interesting results when subsequently processing by any 
code or functions that expect it to be zero-terminated. And a sole 
trailing "%" could occur inadvertently much more easily than with "%" 
followed by a mandatory code.

But this, in your opinion, is perfectly acceptable!

-- 
bartc

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

#65103

On Friday, July 10, 2015 at 12:09:51 PM UTC+1, Bart wrote:
> 
> This could give interesting results when subsequently processing by any 
> code or functions that expect it to be zero-terminated. And a sole 
> trailing "%" could occur inadvertently much more easily than with "%" 
> followed by a mandatory code.
> 
> But this, in your opinion, is perfectly acceptable!
> 
That's a good point.

Someone just has to type

char *message = "sales up by %d%"; 

and he's in UB land, malicious buffer overflow attacks and all that.
But it's very easily done.

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

#65131

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Friday, July 10, 2015 at 12:09:51 PM UTC+1, Bart wrote:
>> 
>> This could give interesting results when subsequently processing by any 
>> code or functions that expect it to be zero-terminated. And a sole 
>> trailing "%" could occur inadvertently much more easily than with "%" 
>> followed by a mandatory code.
>> 
>> But this, in your opinion, is perfectly acceptable!
>> 
> That's a good point.
>
> Someone just has to type
>
> char *message = "sales up by %d%"; 
>
> and he's in UB land, malicious buffer overflow attacks and all that.
> But it's very easily done.

They are already in UB land -- nothing proposed alters that.  What
alters is a statistical assessment of exactly what the UB is likely to
consist of, and how dangerous that might be, in the old and the new
case.  I have no data to contribute to that assessment.

-- 
Ben.

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

#65119

Bartc <bc@freeuk.com> writes:
> On 10/07/2015 11:33, Phil Carmody wrote:
>> Bartc <bc@freeuk.com> writes:
>
>>> But a % at the of a string should be an error.
>>
>> Says who? If you, on what authority? If the C standard, chapter
>> and verse, please?
>
> 7.20.6.1p9 says the behaviour is undefined.

Yes -- but it's 7.21.6.1p6 in C11.

> But whatever that says, under the current rules, a sole "%" at the end 
> of format string produces no output and serves no purpose.

What's your basis for saying it produces no output?  The behavior is
undefined; it could print a '%' character, or the word "PERCENT", or it
could, in principle, do anything.  (It happens to print nothing in the
implementation I'm using.)

-- 
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]

#65251

Phil Carmody <pc+usenet@asdf.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> <snip>
>>>>>>>>  (1) Is there a version of sprintf() without a trailing NULL?
>>
>> <snip>
>>
>>> sprintf already has the right mechanism -- the % syntax.  You could
>>> propose a new conversion specifier which, like %%, denotes a single
>>> character -- a null.  It would mainly be useful in your memprintf
>>> function:
>>>
>>>   memprintf(buffer, "%4u%!", year); // terminated -- min   5 bytes written
>>>   memprintf(buffer, "%4u%!", year); // min   4 bytes written, no null
>>
>> A thought occurs (it does happen)...
>> You could implement what you want as an extension.  Since a trailing %
>> in the format is undefined behaviour, you could have a version of
>> sprintf that interprets such an invalid conversion specifier as a
>> request to omit the trailing null character.
>
> That is an exceptionally elegant way to solve the problem.

It's a clever idea, I'll grant you that.  Not so sure it's a
good way to solve the problem, which IMO doesn't need solving
anyway.

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

#64751

Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> On Monday, July 6, 2015 at 9:31:49 AM UTC-4, John McCue wrote:
> > Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> > > Two questions:
> > >  (1) Is there a version of sprintf() without a trailing NULL?
> > I have not seen any, but what are you trying to accomplish ?

> One example:

>     char buffer[8];
>     sprintf(buffer, "%04u%02%02u", year, month, day);

> > >  (2) Why does sprintf() automatically insert a trailing NULL?
> > 
> > You can see why if you replace the 'trailing NULL' with another
> > character and print out the string.

> Why not options:

>     sprintf0(buffer, "%04u", value);    // NULL-terminated form
>     sprintf(buffer, "%04u\0", value);   // Manually terminated (if needed)

As someone else already pinted out, you'd need a something
different for the "don't output a trailing '\0'" marker...

> Or at this point in support of legacy systems, a new function:
>     rawprintf(buffer, "%04u\0", value); // No NULL-termination by default

because the 's' at the start of sprintf() stands for "string"
and strings are strings because the have a'\0' at the end -
otherwise it would be just a char array.

What would be an sprintf() variant be useful that doens't write
a trailing '\0'? The only reason I can think of is that you want
to write to some memory location of restricted size and the trai-
ling '\0' is one too much. But in that case you can use snprintf()
to ensure that no more that the number of chars you want get out-
put, i.e. in your example

    snprint( buffer, 4, "%04u\n", value );

would probably do the trick (this, of course, assumes that 'value'
never is larger than 9999).
                                 Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

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

#64752

On Monday, July 6, 2015 at 10:16:02 AM UTC-4, Jens Thoms Toerring wrote:
> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> > Or at this point in support of legacy systems, a new function:
> >     rawprintf(buffer, "%04u\0", value); // No NULL-termination by default
> 
> because the 's' at the start of sprintf() stands for "string"
> and strings are strings because the have a'\0' at the end -
> otherwise it would be just a char array.

Agreed.  So why isn't there a version like printf() which doesn't
put a trailing NULL the way sprintf() does, but one that does so
to a memory block?  Maybe something like memprintf() or bufprintf()?

Best regards,
Rick C. Hodgin

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

#64793

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:

> On Monday, July 6, 2015 at 10:16:02 AM UTC-4, Jens Thoms Toerring wrote:
> > Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> > > Or at this point in support of legacy systems, a new function:
> > >     rawprintf(buffer, "%04u\0", value); // No NULL-termination by default
> > 
> > because the 's' at the start of sprintf() stands for "string"
> > and strings are strings because the have a'\0' at the end -
> > otherwise it would be just a char array.
> 
> Agreed.  So why isn't there a version like printf() which doesn't
> put a trailing NULL the way sprintf() does, but one that does so
> to a memory block?

For the same reason that there isn't a version of fopen() which
automatically puts ".txt" at the end of all your filenames: it's going
to be of extremely limited use, so limited that it has no job in any
general library let alone the Standard one.

Richard

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

#64796

On Monday, July 6, 2015 at 3:54:20 PM UTC-4, Richard Bos wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:
> 
> > On Monday, July 6, 2015 at 10:16:02 AM UTC-4, Jens Thoms Toerring wrote:
> > > Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> > > > Or at this point in support of legacy systems, a new function:
> > > >     rawprintf(buffer, "%04u\0", value); // No NULL-termination by default
> > > 
> > > because the 's' at the start of sprintf() stands for "string"
> > > and strings are strings because the have a'\0' at the end -
> > > otherwise it would be just a char array.
> > 
> > Agreed.  So why isn't there a version like printf() which doesn't
> > put a trailing NULL the way sprintf() does, but one that does so
> > to a memory block?
> 
> For the same reason that there isn't a version of fopen() which
> automatically puts ".txt" at the end of all your filenames: it's going
> to be of extremely limited use, so limited that it has no job in any
> general library let alone the Standard one.
> 
> Richard

I don't really see how it could be of limited use.  The sprintf()
function has exceeding utility.  It is only in this one area where
it forces a trailing NULL that it is an issue.  And in googling
today to try to find a solution, I was able to find where several
people had asked the same question.  I'm guessing others had the
same question, but associated the leading "s" with string and just
concluded it would add a trailing null without wishing too hard
for the one that didn't because you could work around it quite
easily with a copy operation.

I can just see wrapping all of the printf-related functions into
a single function with a few flags, and one of them being "include
a trailing null" and that being that.  A tiny up-front wrapper
that passes false in on memprintf() and true on sprintf(). Seems
so simple that it would've been worth the tiny effort by the C
devs back in the day.

Best regards,
Rick C. Hodgin

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

#64799

On 06/07/15 21:31, Rick C. Hodgin wrote:
> On Monday, July 6, 2015 at 3:54:20 PM UTC-4, Richard Bos wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:
>>
<snip>
>> >
>> > [...] So why isn't there a version like printf() which doesn't
>> > put a trailing NULL the way sprintf() does, but one that does so
>> > to a memory block?
>>
>> For the same reason that there isn't a version of fopen() which
>> automatically puts ".txt" at the end of all your filenames: it's going
>> to be of extremely limited use, so limited that it has no job in any
>> general library let alone the Standard one.
>
> I don't really see how it could be of limited use.  The sprintf()
> function has exceeding utility.  It is only in this one area where
> it forces a trailing NULL that it is an issue.

First, a terminology point. In C, "NULL" refers to a macro that expands 
to an implementation-defined null pointer constant. The character that 
terminates a string is known as a "null character".

Now, to the substance of your point. C supports two distinct kinds of 
data (one of which is a subset of the other): completely arbitrary 
(which we normally refer to as 'binary'), and text. The text format is 
clearly intended to be human-readable, whereas binary is not quite so 
friendly. Although there is no hard-and-fast rule about it, we generally 
think of some functions as being suitable for manipulating text, and 
others as suitable for manipulating binary data. For example, fopen(fn, 
"r") is generally used when we expect the data file to contain 
human-readable text, and fopen(fn, "rb") when we expect arbitrary data. 
We use fgets, fprintf, and so on for reading and writing text, and 
fread, fwrite for reading and writing binary data. We use mem* for 
manipulating binary data, and str* for manipulating strings of 
human-readable text. The whole idea of strings is all to do with 
human-readable text. That doesn't mean we can't write programs that read 
text files produced by another program and perform processing based on 
that input, or that we can't write programs that produce text output 
intended for input to another program. But, throughout, the assumption 
is that *at some point* a human may have to read this stuff, so we keep 
to printable, readable characters rather than arbitrary bit patterns. 
The null character is an intrinsic part of the C string model.

When we start to confuse these two ideas, text and binary, we are likely 
to run into problems - not necessarily insurmountable problems, but 
problems nonetheless.

Formatted output is generally intended for human-readable text, and so 
it makes sense to provide printf, fprintf, sprintf, and so on. These 
functions work with strings because strings are how our programs 
interact with humans. And, because they work with strings, they use null 
characters to terminate those strings.

The mem* functions are generally used for manipulating binary data. To 
provide a memprintf function would be to confuse the two models, to 
little if any gain (as far as I can recall, you're the first person I've 
encountered in comp.lang.c who has ever expressed a desire for a 
memprintf function), and at the considerable cost of blurring the 
distinction between binary data and text data.

In short, the game isn't worth the candle.

> And in googling
> today to try to find a solution, I was able to find where several
> people had asked the same question.

Were any of these people asking in comp.lang.c? I don't recall such a 
thread, but then it's been quite a while since I read every single 
article posted on comp.lang.c, so I may have missed it.

> I can just see wrapping all of the printf-related functions into
> a single function with a few flags, and one of them being "include
> a trailing null" and that being that.  A tiny up-front wrapper
> that passes false in on memprintf() and true on sprintf(). Seems
> so simple that it would've been worth the tiny effort by the C
> devs back in the day.

Such a change would fill a much-needed gap.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#64810

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:

> On Monday, July 6, 2015 at 3:54:20 PM UTC-4, Richard Bos wrote:
> > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:
> > 
> > > Agreed.  So why isn't there a version like printf() which doesn't
> > > put a trailing NULL the way sprintf() does, but one that does so
> > > to a memory block?
> > 
> > For the same reason that there isn't a version of fopen() which
> > automatically puts ".txt" at the end of all your filenames: it's going
> > to be of extremely limited use, so limited that it has no job in any
> > general library let alone the Standard one.
> 
> I don't really see how it could be of limited use.

I don't see how it could be of any real use at all, let alone meaningful
use enough to incorporate it into the Standard.

Once again the question to you is: _WHY_ the fsck do you want this!? And
more importantly: _WHY_ should the rest of us pay the price?

Richard

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

#64817

raltbos@xs4all.nl (Richard Bos) writes:

> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:
>
>> On Monday, July 6, 2015 at 3:54:20 PM UTC-4, Richard Bos wrote:
>> > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:
>> > 
>> > > Agreed.  So why isn't there a version like printf() which doesn't
>> > > put a trailing NULL the way sprintf() does, but one that does so
>> > > to a memory block?
>> > 
>> > For the same reason that there isn't a version of fopen() which
>> > automatically puts ".txt" at the end of all your filenames: it's going
>> > to be of extremely limited use, so limited that it has no job in any
>> > general library let alone the Standard one.
>> 
>> I don't really see how it could be of limited use.
>
> I don't see how it could be of any real use at all, let alone meaningful
> use enough to incorporate it into the Standard.
>
> Once again the question to you is: _WHY_ the fsck do you want this!? And
> more importantly: _WHY_ should the rest of us pay the price?

I agree that adding a new suite of functions for this small feature
looks like overkill but there need be no price if it's done through the
existing functions (sprintf and friends).

As I posted elsewhere, the standard could mandate that something
currently undefined (a trailing % being the obvious choice) causes the
function to omit the null.

-- 
Ben.

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

#64821

On Monday, July 6, 2015 at 11:53:30 PM UTC+1, Richard Bos wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:
> 
> > On Monday, July 6, 2015 at 3:54:20 PM UTC-4, Richard Bos wrote:
> > > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:
> > > 
> > > > Agreed.  So why isn't there a version like printf() which doesn't
> > > > put a trailing NULL the way sprintf() does, but one that does so
> > > > to a memory block?
> > > 
> > > For the same reason that there isn't a version of fopen() which
> > > automatically puts ".txt" at the end of all your filenames: it's going
> > > to be of extremely limited use, so limited that it has no job in any
> > > general library let alone the Standard one.
> > 
> > I don't really see how it could be of limited use.
> 
> I don't see how it could be of any real use at all, let alone meaningful
> use enough to incorporate it into the Standard.
> 
> Once again the question to you is: _WHY_ the fsck do you want this!? And
> more importantly: _WHY_ should the rest of us pay the price?
> 
It's useful if you're mixing and matching C with another language.
Most languages do in fact use aciiz strings because of influence from
C, but we can easily imagine one which passes string about as
character buffer / length. Adding a terminating nul means that all 
your buffers are a byte over length, which could cause subtle bugs
down the line, for example when the string is exactly a power of two
and the language X internal incorrectly assumes that it's a single
memory block.

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

#64831

Malcolm McLean wrote:

> On Monday, July 6, 2015 at 11:53:30 PM UTC+1, Richard Bos wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:
>> 
>> > On Monday, July 6, 2015 at 3:54:20 PM UTC-4, Richard Bos wrote:
>> > > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:
>> > > 
>> > > > Agreed.  So why isn't there a version like printf() which doesn't
>> > > > put a trailing NULL the way sprintf() does, but one that does so
>> > > > to a memory block?
>> > > 
>> > > For the same reason that there isn't a version of fopen() which
>> > > automatically puts ".txt" at the end of all your filenames: it's
>> > > going to be of extremely limited use, so limited that it has no job
>> > > in any general library let alone the Standard one.
>> > 
>> > I don't really see how it could be of limited use.
>> 
>> I don't see how it could be of any real use at all, let alone meaningful
>> use enough to incorporate it into the Standard.
>> 
>> Once again the question to you is: _WHY_ the fsck do you want this!? And
>> more importantly: _WHY_ should the rest of us pay the price?
>> 
> It's useful if you're mixing and matching C with another language.
> Most languages do in fact use aciiz strings because of influence from
> C, but we can easily imagine one which passes string about as
> character buffer / length. Adding a terminating nul means that all
> your buffers are a byte over length, which could cause subtle bugs
> down the line, for example when the string is exactly a power of two
> and the language X internal incorrectly assumes that it's a single
> memory block.

And this problem does not exist, when your not nul-terminated string is by 
itself just a byte larger?

But nobody keeps you from creating your own special functions for this. The 
majority of other C programmers might just not need it. 

-- 
Reinhardt

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

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

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

csiph-web