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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#64837

On Tue, 07 Jul 2015 12:45:11 +0800, Reinhardt Behm wrote:
>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. 

yes... 
a=sprintf(b, etc); if(a<0) Error();
b[a] has to be 0
   

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

#64841

On 07/07/2015 03:13, 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.


A compiled language using counted strings would have a *lot* of problems 
if it relied too much on C string functions. But it would be its 
responsibility to fix, not C's.

My own compiled language uses zero-terminated strings because it's 
closely allied to C, and it's a simple solution at this level of language.

My interpreted language has counted, managed strings. There is less 
interaction with C libraries, but sprintf generating an extra zero is 
not one of the problems (mainly, because it uses own tostring() 
functions; but where sprintf() /is/ called, it just uses a buffer with 
plenty of spare space for the zero to be added! And then ignored.)

It's more of a problem having to 'add' a zero-terminator when calling a 
C or OS function, but I don't expect C or the OS to provide a parallel 
set of functions for that purpose!

-- 
Bartc

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

#64842

On Tuesday, July 7, 2015 at 10:31:30 AM UTC+1, Bart wrote:
> On 07/07/2015 03:13, Malcolm McLean wrote:
> 
> A compiled language using counted strings would have a *lot* of problems 
> if it relied too much on C string functions. But it would be its 
> responsibility to fix, not C's.
>
No, it would be C's responsibility.
The C callable interface to language X could be
4 bytes big-endian length
N bytes character data 

C has to set out memory in that layout.
If we further define that a string array is a set of string concatenated in memory,
then you've got problems with the nul (but only if the length goes above 0xFFFFFF).
>
> It's more of a problem having to 'add' a zero-terminator when calling a 
> C or OS function, but I don't expect C or the OS to provide a parallel 
> set of functions for that purpose!
> 
I agree. But language X could well provide an 
XstringtoCstring keyword.  That's a matter for language X, but if the designers 
expect users to have to call a lot of C-convention functions, it would be an obvious 
thing to do.

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

#64844

On 07/07/2015 10:51, Malcolm McLean wrote:
> On Tuesday, July 7, 2015 at 10:31:30 AM UTC+1, Bart wrote:
>> On 07/07/2015 03:13, Malcolm McLean wrote:
>>
>> A compiled language using counted strings would have a *lot* of problems
>> if it relied too much on C string functions. But it would be its
>> responsibility to fix, not C's.
>>
> No, it would be C's responsibility.
> The C callable interface to language X could be
> 4 bytes big-endian length
> N bytes character data
>
> C has to set out memory in that layout.
> If we further define that a string array is a set of string concatenated in memory,
> then you've got problems with the nul (but only if the length goes above 0xFFFFFF).

There are a hundred languages that C could interface to, each with its 
own string handling schemes. It would unreasonable to expect C to 
accommodate all of them.

There would also be less reason for C to care about arbitrary language 
X, than for X to care about C (since a lot of interfaces and API are 
defined via C).

So it is a problem for X, unless X is important and well-known enough. 
(For example, by C having special provision for calling foreign 
functions in Fortran or Pascal.) But usually C is oblivious to any other 
language.

(When I work on a language X, I need to have attributes such 'clang' and 
'windows' for foreign functions, and sometimes types such as 'cstring'. 
I doubt C will be similarly accommodating!)

-- 
Bartc

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

#64845

On Tuesday, July 7, 2015 at 12:11:09 PM UTC+1, Bart wrote:
> On 07/07/2015 10:51, Malcolm McLean wrote:
>
> > C has to set out memory in that layout.
> > If we further define that a string array is a set of string concatenated in memory,
> > then you've got problems with the nul (but only if the length goes above 0xFFFFFF).
> 
> There are a hundred languages that C could interface to, each with its 
> own string handling schemes. It would unreasonable to expect C to 
> accommodate all of them.
> 
C allows you to set up arbitrary binary structures in memory. As long as language X
has an interface defined in terms of such structures, we can write C functions to call
it.
However it's handy to have support for creating a non-nul terminated character buffer.
That's quite a common requirement for interfacing.

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

#64846

On 07/07/2015 13:08, Malcolm McLean wrote:
> On Tuesday, July 7, 2015 at 12:11:09 PM UTC+1, Bart wrote:
>> On 07/07/2015 10:51, Malcolm McLean wrote:
>>
>>> C has to set out memory in that layout.
>>> If we further define that a string array is a set of string concatenated in memory,
>>> then you've got problems with the nul (but only if the length goes above 0xFFFFFF).
>>
>> There are a hundred languages that C could interface to, each with its
>> own string handling schemes. It would unreasonable to expect C to
>> accommodate all of them.
>>
> C allows you to set up arbitrary binary structures in memory. As long as language X
> has an interface defined in terms of such structures, we can write C functions to call
> it.
> However it's handy to have support for creating a non-nul terminated character buffer.
> That's quite a common requirement for interfacing.

There is, in the form of char[] types and mem-functions.

That leaves a few examples such as sprintf, but it's not hard to work 
around the extra 0 byte that is generated, without a whole new set of 
functions.

And suppose the string format had a byte-count as the first character, 
or at the end? These requirements are too specialised.

(I sometimes use a string format that consists of a fixed field of N 
characters, is not zero-terminated, accommodates a string up to N 
characters, *and* it includes a count! But I don't expect a version of 
sprintf to directly write into such a buffer for me.)

-- 
Bartc

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

#64935

Bartc <bc@freeuk.com> writes:
> (I sometimes use a string format that consists of a fixed field of N
> characters, is not zero-terminated, accommodates a string up to N
> characters, *and* it includes a count! But I don't expect a version of
> sprintf to directly write into such a buffer for me.)

You are using the word "string" ways which contradict the definition
of the term in the C standard.

string != array of char, nor pointer to the first element thereof

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]

#64945

On 08/07/2015 18:20, Phil Carmody wrote:
> Bartc <bc@freeuk.com> writes:
>> (I sometimes use a string format that consists of a fixed field of N
>> characters, is not zero-terminated, accommodates a string up to N
>> characters, *and* it includes a count! But I don't expect a version of
>> sprintf to directly write into such a buffer for me.)
>
> You are using the word "string" ways which contradict the definition
> of the term in the C standard.
>
> string != array of char, nor pointer to the first element thereof

I'm using 'string' in the wider sense of how it's used in computing.

The context made it clear that I didn't mean C's very narrow definition. 
What should I have used? Any alternative would have made it harder to 
understand.

-- 
Bartc

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

#64977

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

> Bartc <bc@freeuk.com> writes:
> > (I sometimes use a string format that consists of a fixed field of N
> > characters, is not zero-terminated, accommodates a string up to N
> > characters, *and* it includes a count! But I don't expect a version of
> > sprintf to directly write into such a buffer for me.)
> 
> You are using the word "string" ways which contradict the definition
> of the term in the C standard.

Which, ITYF if you read the rest of the thread, is the point of his
objection - and mine.

Richard

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

#65225

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

> On Tuesday, July 7, 2015 at 12:11:09 PM UTC+1, Bart wrote:
>> On 07/07/2015 10:51, Malcolm McLean wrote:
>>
>>> C has to set out memory in that layout.  If we further define
>>> that a string array is a set of string concatenated in memory,
>>> then you've got problems with the nul (but only if the length
>>> goes above 0xFFFFFF).
>>
>> There are a hundred languages that C could interface to, each
>> with its own string handling schemes.  It would unreasonable to
>> expect C to accommodate all of them.
>
> C allows you to set up arbitrary binary structures in memory.
> [snip]

Correction:  C allows you to set up arbitrary binary structures
in memory of the abstract machine.  Nornally there is a one-to-one
mapping between memory in the abstract machine and memory in the
real machine, but there doesn't have to be.

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

#64876

> I don't really see how it could be of limited use.  

Neither do I:  I say that if it were available, you shouldn't
use it, on the grounds of runtime efficiency.

Many people avoid functions that produce non-nul-terminated non-strings
on the grounds that it's a programming error (and possible security
problem) waiting to happen.  (see also strncpy().  Even though
strncpy() does have a use - copying a string to a character array
of known size, where if it's of maximum length there is no NUL
terminator.  Were it not for the historical format of UNIX directories
(14-character array for the name), I'd recommend never having
included  strncpy() in standard C.  )

> The sprintf()
> function has exceeding utility.  
> It is only in this one area where
> it forces a trailing NULL that it is an issue.  

WHY is it an issue?  You like wasting memory to save 1 byte in a
buffer?  You like wasting lots of memory read accesses to avoid 1
write?  Is there also an issue that there is no variant of sprintf()
that appends a euro symbol to the string without being asked?

What do you gain?
	- It saves 1 character of buffer size to hold the '\0'.
	- It saves one memory access to store the '\0'.

What do you lose?
	- You need at least 1, and probably 2 extra characters
	  in the format string, or else you need to pass an
	  additional argument, which is likely to take 4 bytes..
	- If you use the variant function, it takes memory 
	  accesses to interpret the additional characters in the
	  format string.
	- You have an additioal function that occupies memory.
	- If you have a common subroutine, or one calls the other,
	  you have 1 additional function call overhead, with one
	  additional argument passed, and you probably end up
	  adding this overhead to sprintf() as well as the new
	  function.
	
> 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.

Usually you can work around it much more easily:  pretend that
the output is one character shorter.  

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

In terms of the additional manual-reading to figure out which
function to use, it's a huge cost.

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

#64880

Gordon Burditt wrote:
> [snip]

Wow.

Best regards,
Rick C. Hodgin

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

#64753

On Monday, July 6, 2015 at 10:16:02 AM UTC-4, Jens Thoms Toerring wrote:
> 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).

As I understand it, snprintf() still puts the trailing NULL.

Best regards,
Rick C. Hodgin

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

#64776

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:
> > 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).

> As I understand it, snprintf() still puts the trailing NULL.

Uups, sorry, you're correct. I'm obviously still suffering from
the heat wave of the last days, brains processing speed still
reduced due to overheating;-)
                                 Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

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

#64758

jt@toerring.de (Jens Thoms Toerring) writes:
[...]
> 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).

snprintf always writes a trailing null character.  In this case, the
output will be truncated to 3 digits (and snprintf will return 4 to
indicate how many characters would have been written if there were
enough room).

Replying to other articles in this thread, NULL is a null *pointer*
constant, and should not be used to refer to the null character.

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

#64762

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

> Two questions:
>
>   (1) Is there a version of sprintf() without a trailing NULL?

Not that I'm aware of.

>   (2) Why does sprintf() automatically insert a trailing NULL?

Because it's a string function.  C doesn't have a native "string" type,
but the standard library implements them.  To the best of my knowledge,
the only string function that doesn't maintain the trailing null byte is
strncpy(), whose behavior is different enough from the rest that it
could be argued it isn't a string function.

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

#64763

On Monday, July 6, 2015 at 2:17:17 PM UTC+1, Rick C. Hodgin wrote:
> Two questions:
> 
>   (1) Is there a version of sprintf() without a trailing NULL?
>   (2) Why does sprintf() automatically insert a trailing NULL?
> 
Kind of. You can use strncpy(), which doesn't add a trailing null. But you can't
pass parameters to it.
strncpy was designed for writing to database structures which typically had fixed
fields, which weren't nil-terminated unless they needed right padding.
sprintf() was designed as a safe replacement for sprint(), which creates a
string intended for use by other C functions. If it's not nul-terminated, it's
not safe to pass about.

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

#64769

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Monday, July 6, 2015 at 2:17:17 PM UTC+1, Rick C. Hodgin wrote:
>> Two questions:
>> 
>>   (1) Is there a version of sprintf() without a trailing NULL?
>>   (2) Why does sprintf() automatically insert a trailing NULL?
>> 
> Kind of. You can use strncpy(), which doesn't add a trailing null. But you can't
> pass parameters to it.
> strncpy was designed for writing to database structures which typically had fixed
> fields, which weren't nil-terminated unless they needed right padding.
> sprintf() was designed as a safe replacement for sprint(), which creates a
> string intended for use by other C functions. If it's not nul-terminated, it's
> not safe to pass about.

What is "sprint()"?  Are you thinking of snprintf(), which was designed
as a safe(r) replacement for sprintf()?

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

#64768

On Monday, July 6, 2015 at 9:17:17 AM UTC-4, Rick C. Hodgin wrote:
> Two questions:
> 
>   (1) Is there a version of sprintf() without a trailing NULL?
>   (2) Why does sprintf() automatically insert a trailing NULL?
> 
> TYIA!
> 
> Best regards,
> Rick C. Hodgin

I think I will just write my own.  I'll have to eventually anyway.

I don't use the full set of printf format specifiers, and will add
the ones I need as they come up.  I've also always had a dream of
using sprintf(buffer, "%3s", "abcdef"); and having it only copy
three characters, but I think I saw today in a google search where
using sprintf(buffer, "%.*s", 3, "abcdef"); would work. I like that,
but would prefer the %3s syntax.  Testing it just now it works in
Visual Studio and GCC 5.1.

Best regards,
Rick C. Hodgin

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

#64770

On Monday, July 6, 2015 at 11:54:00 AM UTC-4, Rick C. Hodgin wrote:
> On Monday, July 6, 2015 at 9:17:17 AM UTC-4, Rick C. Hodgin wrote:
> > Two questions:
> > 
> >   (1) Is there a version of sprintf() without a trailing NULL?
> >   (2) Why does sprintf() automatically insert a trailing NULL?
> > 
> > TYIA!
> > 
> > Best regards,
> > Rick C. Hodgin
> 
> I think I will just write my own.  I'll have to eventually anyway.
> 
> I don't use the full set of printf format specifiers, and will add
> the ones I need as they come up.  I've also always had a dream of
> using sprintf(buffer, "%3s", "abcdef"); and having it only copy
> three characters, but I think I saw today in a google search where
> using sprintf(buffer, "%.*s", 3, "abcdef"); would work. I like that,
> but would prefer the %3s syntax.

> Testing it just now it works in Visual Studio and GCC 5.1.
          ^^

The %.*s uses the passed parameter.  Using %.3s uses the hard-coded length.

> Best regards,
> Rick C. Hodgin

Best regards,
Rick C. Hodgin

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

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

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

csiph-web