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

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

How to copy a string safely and efficiently in C?

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

Contents

  How to copy a string safely and efficiently in C? will hunt <glovepm@gmail.com> - 2016-09-01 18:50 -0700
    Re: How to copy a string safely and efficiently in C? John Gordon <gordon@panix.com> - 2016-09-02 01:58 +0000
      Re: How to copy a string safely and efficiently in C? will hunt <glovepm@gmail.com> - 2016-09-01 19:40 -0700
        Re: How to copy a string safely and efficiently in C? Geoff <geoff@invalid.invalid> - 2016-09-01 20:29 -0700
          Re: How to copy a string safely and efficiently in C? James Kuyper <jameskuyper@verizon.net> - 2016-09-02 12:29 -0400
        Re: How to copy a string safely and efficiently in C? asetofsymbols@gmail.com - 2016-09-12 13:09 -0700
          Re: How to copy a string safely and efficiently in C? Keith Thompson <kst-u@mib.org> - 2016-09-12 15:30 -0700
      Re: How to copy a string safely and efficiently in C? Keith Thompson <kst-u@mib.org> - 2016-09-01 23:08 -0700
      Re: How to copy a string safely and efficiently in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-04 23:59 -0700
    Re: How to copy a string safely and efficiently in C? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-09-01 21:12 -0600
      Re: How to copy a string safely and efficiently in C? <william@wilbur.25thandClement.com> - 2016-09-01 22:12 -0700
    Re: How to copy a string safely and efficiently in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-01 23:58 -0700
    Re: How to copy a string safely and efficiently in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-02 10:42 +0100
      Re: How to copy a string safely and efficiently in C? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 22:23 -0700
        Re: How to copy a string safely and efficiently in C? Keith Thompson <kst-u@mib.org> - 2016-09-04 23:20 -0700
          Re: How to copy a string safely and efficiently in C? mark.bluemel@gmail.com - 2016-09-05 01:03 -0700
            Re: How to copy a string safely and efficiently in C? Keith Thompson <kst-u@mib.org> - 2016-09-05 01:46 -0700
          Re: How to copy a string safely and efficiently in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-05 10:30 +0100
            Re: How to copy a string safely and efficiently in C? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-10 11:25 -0700
          Re: How to copy a string safely and efficiently in C? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-11 06:23 -0700
            Re: How to copy a string safely and efficiently in C? supercat@casperkitty.com - 2016-09-11 15:41 -0700
              Re: How to copy a string safely and efficiently in C? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-11 23:40 -0700
                Re: How to copy a string safely and efficiently in C? Ian Collins <ian-news@hotmail.com> - 2016-09-12 21:04 +1200
                  Re: How to copy a string safely and efficiently in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-09-12 09:21 +0000
                    Re: How to copy a string safely and efficiently in C? Ian Collins <ian-news@hotmail.com> - 2016-09-12 21:33 +1200
                    Re: How to copy a string safely and efficiently in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-12 10:41 +0100
                      Re: How to copy a string safely and efficiently in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-09-12 10:48 +0000
                  Re: How to copy a string safely and efficiently in C? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-12 07:04 -0700
    Re: How to copy a string safely and efficiently in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-09-02 12:36 +0100
      Re: How to copy a string safely and efficiently in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-02 14:24 +0100
        Re: How to copy a string safely and efficiently in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-09-02 14:51 +0100
        Re: How to copy a string safely and efficiently in C? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 23:42 -0700
    Re: How to copy a string safely and efficiently in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-09-02 18:05 +0100
      Re: How to copy a string safely and efficiently in C? Ike Naar <ike@iceland.freeshell.org> - 2016-09-02 19:48 +0000
    Re: How to copy a string safely and efficiently in C? cross@spitfire.i.gajendra.net (Dan Cross) - 2016-09-13 01:45 +0000
      Re: How to copy a string safely and efficiently in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-13 11:06 +0100
        Re: How to copy a string safely and efficiently in C? cross@spitfire.i.gajendra.net (Dan Cross) - 2016-09-13 14:09 +0000
          Re: How to copy a string safely and efficiently in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-13 15:30 +0100
            Re: How to copy a string safely and efficiently in C? cross@spitfire.i.gajendra.net (Dan Cross) - 2016-09-13 14:52 +0000
              Re: How to copy a string safely and efficiently in C? cross@spitfire.i.gajendra.net (Dan Cross) - 2016-09-13 14:54 +0000
                Re: How to copy a string safely and efficiently in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-13 17:18 +0100
                  Re: How to copy a string safely and efficiently in C? cross@spitfire.i.gajendra.net (Dan Cross) - 2016-09-13 18:15 +0000
                Re: How to copy a string safely and efficiently in C? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-13 20:30 -0700
                  Re: How to copy a string safely and efficiently in C? cross@spitfire.i.gajendra.net (Dan Cross) - 2016-09-15 14:03 +0000
                    Re: How to copy a string safely and efficiently in C? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-15 12:32 -0700
                      Re: How to copy a string safely and efficiently in C? luser droog <luser.droog@gmail.com> - 2016-09-15 12:45 -0700
                        Re: How to copy a string safely and efficiently in C? supercat@casperkitty.com - 2016-09-15 13:00 -0700
                          Re: How to copy a string safely and efficiently in C? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-09-15 14:52 -0600
                            Re: How to copy a string safely and efficiently in C? Keith Thompson <kst-u@mib.org> - 2016-09-15 16:04 -0700
                              Re: How to copy a string safely and efficiently in C? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-09-15 15:52 -0600
                                Re: How to copy a string safely and efficiently in C? Keith Thompson <kst-u@mib.org> - 2016-09-15 17:07 -0700
                          Re: How to copy a string safely and efficiently in C? Keith Thompson <kst-u@mib.org> - 2016-09-15 15:53 -0700
                            Re: How to copy a string safely and efficiently in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-09-15 22:17 +0100
                              Re: How to copy a string safely and efficiently in C? Keith Thompson <kst-u@mib.org> - 2016-09-15 17:01 -0700
                            Re: How to copy a string safely and efficiently in C? supercat@casperkitty.com - 2016-09-15 16:36 -0700
                              Re: How to copy a string safely and efficiently in C? Keith Thompson <kst-u@mib.org> - 2016-09-15 19:19 -0700
                                Re: How to copy a string safely and efficiently in C? supercat@casperkitty.com - 2016-09-15 21:39 -0700
                        Re: How to copy a string safely and efficiently in C? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-16 06:17 -0700
                          Re: How to copy a string safely and efficiently in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-16 07:04 -0700
                            Re: How to copy a string safely and efficiently in C? supercat@casperkitty.com - 2016-09-16 09:11 -0700
                            Re: How to copy a string safely and efficiently in C? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-22 22:24 -0700
                      Re: How to copy a string safely and efficiently in C? cross@spitfire.i.gajendra.net (Dan Cross) - 2016-09-19 15:15 +0000
      Re: How to copy a string safely and efficiently in C? Richard Damon <Richard@Damon-Family.org> - 2016-09-13 08:19 -0400
        Re: How to copy a string safely and efficiently in C? cross@spitfire.i.gajendra.net (Dan Cross) - 2016-09-13 14:07 +0000
          Re: How to copy a string safely and efficiently in C? supercat@casperkitty.com - 2016-09-13 07:57 -0700
            Re: How to copy a string safely and efficiently in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-13 17:33 +0100
              Re: How to copy a string safely and efficiently in C? cross@spitfire.i.gajendra.net (Dan Cross) - 2016-09-13 18:13 +0000
              Re: How to copy a string safely and efficiently in C? supercat@casperkitty.com - 2016-09-13 11:30 -0700
                Re: How to copy a string safely and efficiently in C? cross@spitfire.i.gajendra.net (Dan Cross) - 2016-09-13 20:03 +0000
                  Re: How to copy a string safely and efficiently in C? supercat@casperkitty.com - 2016-09-13 13:38 -0700
                    Re: How to copy a string safely and efficiently in C? cross@spitfire.i.gajendra.net (Dan Cross) - 2016-09-13 21:39 +0000
                Re: How to copy a string safely and efficiently in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-13 23:26 +0100
              Re: How to copy a string safely and efficiently in C? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-13 16:14 -0700
      Re: How to copy a string safely and efficiently in C? BartC <bc@freeuk.com> - 2016-09-13 15:59 +0100
      Re: How to copy a string safely and efficiently in C? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-13 16:07 -0700
        Re: How to copy a string safely and efficiently in C? cross@spitfire.i.gajendra.net (Dan Cross) - 2016-09-14 00:24 +0000

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

#93423

cross@spitfire.i.gajendra.net (Dan Cross) writes:

> In article <nr93rt$lgt$1@reader2.panix.com>,
> Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>In article <87wpifq3db.fsf@bsb.me.uk>,
>>Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
>>>> [snip]
>>>
>>>The original assumed that size was at least 1.  If that's reasonable you
>>>can test
>>>
>>>  src[size - 1] && size > 1 && dst[size - 2]
>>>
>>>and if size could be 0 the test gets more complicated still but not very
>>>much more complicated.  The most obvious one being
>>>
>>>  size && src[size - 1] && size > 1 && dst[size - 2]
>>>
>>>It may not be of any practical value, but I think it's interesting to
>>>know that O(1) overflow detection is always possible in these cases.
>>
>>Yes yes, that's true, but surely we can see that one approaches a point
>>of diminishing returns with these sorts of shenanigans. One could simply
>>use strlcpy() and avoid all of this, no?
>
> And to wit: Surely one would not expect a reasonable program to duplicate
> these checks at every strncat() call site. Instead, one would wrap this
> sequence of code up into some kind of function; at that point, one may as
> well simply call the 8 line strlcpy().

Yes, of course.  That's the "it may not be of any practical value" part.

I suspect we've kept this going simply because my interests differ from
yours.  Nowadays, programming is largely an intellectual exercise for
me, so I like to show alternatives, especially when they seem
non-obvious.  I don't expect anyone to prefer the above over other, more
robust, engineering solutions.  I suppose the trouble is you worry that
readers won't make the assessment correctly whereas I just assume they
will do.

-- 
Ben.

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

#93429

In article <87r38npyd7.fsf@bsb.me.uk>,
Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>> And to wit: Surely one would not expect a reasonable program to duplicate
>> these checks at every strncat() call site. Instead, one would wrap this
>> sequence of code up into some kind of function; at that point, one may as
>> well simply call the 8 line strlcpy().
>
>Yes, of course.  That's the "it may not be of any practical value" part.
>
>I suspect we've kept this going simply because my interests differ from
>yours.  Nowadays, programming is largely an intellectual exercise for
>me, so I like to show alternatives, especially when they seem
>non-obvious.  I don't expect anyone to prefer the above over other, more
>robust, engineering solutions.  I suppose the trouble is you worry that
>readers won't make the assessment correctly whereas I just assume they
>will do.

Ah, yes; I think you are right there.  I have enjoyed the back-and-forth,
though.

	- Dan C.

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

#93456

cross@spitfire.i.gajendra.net (Dan Cross) writes:

> In article <nr93rt$lgt$1@reader2.panix.com>,
> Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> In article <87wpifq3db.fsf@bsb.me.uk>,
>> Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
>>>> [snip]
>>>
>>> The original assumed that size was at least 1.  If that's reasonable you
>>> can test
>>>
>>>  src[size - 1] && size > 1 && dst[size - 2]
>>>
>>> and if size could be 0 the test gets more complicated still but not very
>>> much more complicated.  The most obvious one being
>>>
>>>  size && src[size - 1] && size > 1 && dst[size - 2]
>>>
>>> It may not be of any practical value, but I think it's interesting to
>>> know that O(1) overflow detection is always possible in these cases.
>>
>> Yes yes, that's true, but surely we can see that one approaches a point
>> of diminishing returns with these sorts of shenanigans.  One could simply
>> use strlcpy() and avoid all of this, no?
>
> And to wit:  Surely one would not expect a reasonable program to duplicate
> these checks at every strncat() call site.  Instead, one would wrap this
> sequence of code up into some kind of function;  at that point, one may as
> well simply call the 8 line strlcpy().

The safe copy instruction sequence should of course be wrapped up
in a function.  In my view though there are several reasons to
prefer not using strlcpy() for this application.

One, strlcpy() might not be available or in an obvious library.
That means navigating a configuration question so it can be
provided if not there.  (Sadly I have run into this very issue
in some open source programs.)  A further complication is
that it might be provided by the implementation, as the name
is in the reserved name space.

Two, in the case that truncation occurs, strlcpy() reads more
than it needs to (ie, if all we care about is whether or not
truncation occurred).  That is somehow wasteful.

Three, given what strlcpy() returns, truncation is not detectable
directly but needs a comparison against the passed length
argument value, which might mean having to put that value in a
temporary so it can subsequently compared.  Of course it isn't
hard to do that but it makes the code a bit messy.

An alternative is to supply the truncation-detecting safe copy
function directly, using only standard functions.  This can be
done with, eg, memchr() and memmove(), in just a few lines of
code (as shown in the example posted in a cousin thread not
too long ago).

I appreciate the value of strlcpy() et al.  For this particular
application however it seems like not quite the right fit.

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

#93540

In article <kfnvaxzi2du.fsf@x-alumni2.alumni.caltech.edu>,
Tim Rentsch  <txr@alumni.caltech.edu> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>> In article <nr93rt$lgt$1@reader2.panix.com>,
>> Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>> [snip]
>>>
>>> Yes yes, that's true, but surely we can see that one approaches a point
>>> of diminishing returns with these sorts of shenanigans.  One could simply
>>> use strlcpy() and avoid all of this, no?
>>
>> And to wit:  Surely one would not expect a reasonable program to duplicate
>> these checks at every strncat() call site.  Instead, one would wrap this
>> sequence of code up into some kind of function;  at that point, one may as
>> well simply call the 8 line strlcpy().
>
>The safe copy instruction sequence should of course be wrapped up
>in a function.  In my view though there are several reasons to
>prefer not using strlcpy() for this application.

Thanks, you raise some valid points but it begs the question: to
which application do you refer?  The original poster simply asked
"How to copy a string safely and efficinetly in C?", with an explicit
question about a choice between two functions: snprintf() and
strncpy().  As far as I know, a more specific context was not given.

>One, strlcpy() might not be available or in an obvious library.
>That means navigating a configuration question so it can be
>provided if not there.  (Sadly I have run into this very issue
>in some open source programs.)  A further complication is
>that it might be provided by the implementation, as the name
>is in the reserved name space.

Yes, this is unfortunate; I rather hope that they will standardize
it in an upcoming revision of the language, but I have some doubts.

It is, however, easy to write oneself -- or simply take one of the
available open source versions (mine is public domain, OpenBSD's
is under a permissive license).  Conflict with a system-supplied
version could be an issue in portable programs, but there are
well-known techniques for working around that (e.g., separate
compilation and conditional compilation based on platform, etc).

>Two, in the case that truncation occurs, strlcpy() reads more
>than it needs to (ie, if all we care about is whether or not
>truncation occurred).  That is somehow wasteful.

This is valid; I suspect the original rationale was something along
the lines of, "the next question one may ask after determining that
the string was truncated is how much more buffer was needed for
it?"

But yeah, it could just return a boolean indicating whether it
successfully copied the entirety of the source string.  Indeed,
this is what the original version in the Akaros kernel did before
I rewrote it.

Incidentally: I went on a search for strncpy() in that kernel at
one point; out of something like 80ish call sites, only 4 were
correct.

>Three, given what strlcpy() returns, truncation is not detectable
>directly but needs a comparison against the passed length
>argument value, which might mean having to put that value in a
>temporary so it can subsequently compared.  Of course it isn't
>hard to do that but it makes the code a bit messy.

This is a very valid criticism.

>An alternative is to supply the truncation-detecting safe copy
>function directly, using only standard functions.  This can be
>done with, eg, memchr() and memmove(), in just a few lines of
>code (as shown in the example posted in a cousin thread not
>too long ago).
>
>I appreciate the value of strlcpy() et al.  For this particular
>application however it seems like not quite the right fit.

I'm still not quite sure what application you are referring to.
Certainly, for the filesystem thing or similar applications,
strncpy() really does do what one wants.

	- Dan C.

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

#93568

cross@spitfire.i.gajendra.net (Dan Cross) writes:

> In article <kfnvaxzi2du.fsf@x-alumni2.alumni.caltech.edu>,
> Tim Rentsch  <txr@alumni.caltech.edu> wrote:
>> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>> In article <nr93rt$lgt$1@reader2.panix.com>,
>>> Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>>> [snip]
>>>>
>>>> Yes yes, that's true, but surely we can see that one approaches a point
>>>> of diminishing returns with these sorts of shenanigans.  One could simply
>>>> use strlcpy() and avoid all of this, no?
>>>
>>> And to wit:  Surely one would not expect a reasonable program to duplicate
>>> these checks at every strncat() call site.  Instead, one would wrap this
>>> sequence of code up into some kind of function;  at that point, one may as
>>> well simply call the 8 line strlcpy().
>>
>> The safe copy instruction sequence should of course be wrapped up
>> in a function.  In my view though there are several reasons to
>> prefer not using strlcpy() for this application.
>
> Thanks, you raise some valid points but it begs the question:  to
> which application do you refer?  The original poster simply asked
> "How to copy a string safely and efficinetly in C?", with an explicit
> question about a choice between two functions:  snprintf() and
> strncpy().  As far as I know, a more specific context was not given.

Sorry, probably I should have been more explicit.  The
application I meant is the one I thought the discussion had
converged on, namely, safe copying of strings with an easy
way to detect that the source string was truncated.

>> One, strlcpy() might not be available or in an obvious library.
>> That means navigating a configuration question so it can be
>> provided if not there.  (Sadly I have run into this very issue
>> in some open source programs.)  A further complication is
>> that it might be provided by the implementation, as the name
>> is in the reserved name space.
>
> Yes, this is unfortunate;  I rather hope that they will standardize
> it in an upcoming revision of the language, but I have some doubts.

Ditto (and sadly, ditto).

> It is, however, easy to write oneself -- or simply take one of the
> available open source versions (mine is public domain, OpenBSD's
> is under a permissive license).  Conflict with a system-supplied
> version could be an issue in portable programs, but there are
> well-known techniques for working around that (e.g., separate
> compilation and conditional compilation based on platform, etc).

Right, that's basically what I was saying, although my emphasis
was different.

>> Two, in the case that truncation occurs, strlcpy() reads more
>> than it needs to (ie, if all we care about is whether or not
>> truncation occurred).  That is somehow wasteful.
>
> This is valid;  I suspect the original rationale was something along
> the lines of, "the next question one may ask after determining that
> the string was truncated is how much more buffer was needed for
> it?"

Definitely, returning the length that would be needed is a
useful functionality, in those cases that want to do something
along those lines.

> But yeah, it could just return a boolean indicating whether it
> successfully copied the entirety of the source string.  Indeed,
> this is what the original version in the Akaros kernel did before
> I rewrote it.

Interesting.  It has been many years since I used a BSD system,
and I haven't paid much attention (or probably any) for how
those interfaces may have changed over time or between systems.

> Incidentally:  I went on a search for strncpy() in that kernel at
> one point;  out of something like 80ish call sites, only 4 were
> correct.

The problem with strncpy() is not what functionality it provides
but the name used to provide it.  In retrospect I think it should
have been called something like strnotwhatyouexpectcpy().

>> Three, given what strlcpy() returns, truncation is not detectable
>> directly but needs a comparison against the passed length
>> argument value, which might mean having to put that value in a
>> temporary so it can subsequently compared.  Of course it isn't
>> hard to do that but it makes the code a bit messy.
>
> This is a very valid criticism.
>
>> An alternative is to supply the truncation-detecting safe copy
>> function directly, using only standard functions.  This can be
>> done with, eg, memchr() and memmove(), in just a few lines of
>> code (as shown in the example posted in a cousin thread not
>> too long ago).
>>
>> I appreciate the value of strlcpy() et al.  For this particular
>> application however it seems like not quite the right fit.
>
> I'm still not quite sure what application you are referring to.
> Certainly, for the filesystem thing or similar applications,
> strncpy() really does do what one wants.

Oh yes, strncpy() does the job it was meant to do very well.
Now if only more people knew what that job is....

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

#93571

On Thursday, September 15, 2016 at 2:32:39 PM UTC-5, Tim Rentsch wrote:
> cross@spitfire.i.gajendra.net (Dan Cross) writes:
> 
> 
> > Incidentally:  I went on a search for strncpy() in that kernel at
> > one point;  out of something like 80ish call sites, only 4 were
> > correct.
> 
> The problem with strncpy() is not what functionality it provides
> but the name used to provide it.  In retrospect I think it should
> have been called something like strnotwhatyouexpectcpy().
> 

I suggest char_array_cpy() or fixed_field_cpy(). Maybe *fld*.

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

#93572

On Thursday, September 15, 2016 at 2:46:11 PM UTC-5, luser droog wrote:
> On Thursday, September 15, 2016 at 2:32:39 PM UTC-5, Tim Rentsch wrote:
> > The problem with strncpy() is not what functionality it provides
> > but the name used to provide it.  In retrospect I think it should
> > have been called something like strnotwhatyouexpectcpy().
> 
> I suggest char_array_cpy() or fixed_field_cpy(). Maybe *fld*.

Since the functions were defined before the preprocessor became an
essential part of the language, the names were limited to six characters;
I think it might have been good to apply a looser constraint that all
library functions must be *unique* in the first 6 characters, but I don't
think fixed_ would be a particularly good name even then.  From a naming
standpoint, I think what's important is that the function converts zero-
terminated strings to zero-padded strings; perhaps "strpad" might be a
good name if the behavior when the source and destination pointers are
equal was defined as padding a string in-place (I'd have a hard time
imagining an implementation where that guarantee would have any cost
beyond requiring that compilers not optimize out what would otherwise
be useful code).

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

#93575

supercat@casperkitty.com writes:

> On Thursday, September 15, 2016 at 2:46:11 PM UTC-5, luser droog wrote:
>> On Thursday, September 15, 2016 at 2:32:39 PM UTC-5, Tim Rentsch wrote:
>> > The problem with strncpy() is not what functionality it provides
>> > but the name used to provide it.  In retrospect I think it should
>> > have been called something like strnotwhatyouexpectcpy().
>> 
>> I suggest char_array_cpy() or fixed_field_cpy(). Maybe *fld*.
>
> Since the functions were defined before the preprocessor became an
> essential part of the language, the names were limited to six characters;
> I think it might have been good to apply a looser constraint that all
> library functions must be *unique* in the first 6 characters, but I don't
> think fixed_ would be a particularly good name even then.  From a naming
> standpoint, I think what's important is that the function converts zero-
> terminated strings to zero-padded strings; perhaps "strpad" might be a
> good name if the behavior when the source and destination pointers are
> equal was defined as padding a string in-place (I'd have a hard time
> imagining an implementation where that guarantee would have any cost
> beyond requiring that compilers not optimize out what would otherwise
> be useful code).

The better question would be why something whose definition was so
idiosyncratic and whose use was so specialized was ever in the standard
library in the first place.

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

#93579

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
[...]
> The better question would be why something whose definition was so
> idiosyncratic and whose use was so specialized was ever in the standard
> library in the first place.

[referring to strncpy]

One possibility is that it's because early Unix systems used a
fixed-width character array to store file names in directory entries,
and strncpy() was useful for manipulating them.

It's not clear that that's the actual rationale, but it's plausible.

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

#93582

Keith Thompson <kst-u@mib.org> writes:

> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> [...]
>> The better question would be why something whose definition was so
>> idiosyncratic and whose use was so specialized was ever in the standard
>> library in the first place.
>
> [referring to strncpy]
>
> One possibility is that it's because early Unix systems used a
> fixed-width character array to store file names in directory entries,
> and strncpy() was useful for manipulating them.
>
> It's not clear that that's the actual rationale, but it's plausible.

I've always been under the impression that that is what it's for -- it
doesn't answer why it's in the standard library.

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

#93584

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>> [...]
>>> The better question would be why something whose definition was so
>>> idiosyncratic and whose use was so specialized was ever in the standard
>>> library in the first place.
>>
>> [referring to strncpy]
>>
>> One possibility is that it's because early Unix systems used a
>> fixed-width character array to store file names in directory entries,
>> and strncpy() was useful for manipulating them.
>>
>> It's not clear that that's the actual rationale, but it's plausible.
>
> I've always been under the impression that that is what it's for -- it
> doesn't answer why it's in the standard library.

The C standard library wasn't designed as a coherent whole.
It evolved.  strncpy was useful at the time, so it went in.

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

#93576

supercat@casperkitty.com writes:
> On Thursday, September 15, 2016 at 2:46:11 PM UTC-5, luser droog wrote:
>> On Thursday, September 15, 2016 at 2:32:39 PM UTC-5, Tim Rentsch wrote:
>> > The problem with strncpy() is not what functionality it provides
>> > but the name used to provide it.  In retrospect I think it should
>> > have been called something like strnotwhatyouexpectcpy().
>> 
>> I suggest char_array_cpy() or fixed_field_cpy(). Maybe *fld*.
>
> Since the functions were defined before the preprocessor became an
> essential part of the language, the names were limited to six characters;
> I think it might have been good to apply a looser constraint that all
> library functions must be *unique* in the first 6 characters, but I don't
> think fixed_ would be a particularly good name even then.
[...]

C90 required external names to be unique in the first 6 characters,
possibly ignoring case.  The C90 standard library had several
functions whose names are longer than 6 characters; vprintf, at 8
characters, is the longest I found in a quick search.

There might have been some pre-ANSI implementations that didn't
permit external names longer than 6 character -- but surely strncat,
at 7 characters, must have been added after any such restrictions
were removed.

How is the preprocessor relevant?

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

#93581

On 15/09/16 23:53, Keith Thompson wrote:
<snip>
>
> C90 required external names to be unique in the first 6 characters,
> possibly ignoring case.  The C90 standard library had several
> functions whose names are longer than 6 characters; vprintf, at 8
> characters, is the longest I found in a quick search.

I make it 7. Did you mean vfprintf?

<snip>

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

#93583

Richard Heathfield <rjh@cpax.org.uk> writes:
> On 15/09/16 23:53, Keith Thompson wrote:
> <snip>
>>
>> C90 required external names to be unique in the first 6 characters,
>> possibly ignoring case.  The C90 standard library had several
>> functions whose names are longer than 6 characters; vprintf, at 8
>> characters, is the longest I found in a quick search.
>
> I make it 7. Did you mean vfprintf?
>
> <snip>

Yes.  (And that 'f' at the end means I can't even claim that my
'f' key is broken.)

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

#93591

On Thursday, September 15, 2016 at 3:56:14 PM UTC-5, Keith Thompson wrote:
> supercat writes:
> > Since the functions were defined before the preprocessor became an
> > essential part of the language, the names were limited to six characters;
> > I think it might have been good to apply a looser constraint that all
> > library functions must be *unique* in the first 6 characters, but I don't
> > think fixed_ would be a particularly good name even then.
> [...]
> 
> C90 required external names to be unique in the first 6 characters,
> possibly ignoring case.  The C90 standard library had several
> functions whose names are longer than 6 characters; vprintf, at 8
> characters, is the longest I found in a quick search.

> How is the preprocessor relevant?

If implementations were allowed to regard external names starting with
some character sequence as reserved, then the preprocessor could get
around the 6-character limit for function names, by having an
implementation assign a short implementation-specific external name for
each library function.

#define strcpy_with_pad _Q382x

Note that a similar approach may be useful on platforms which have
configurable integer sizes, e.g.

#if INT_MAX==32767
#define printf __printf16
#else
#define printf __printf32
#endif

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

#93594

supercat@casperkitty.com writes:
> On Thursday, September 15, 2016 at 3:56:14 PM UTC-5, Keith Thompson wrote:
>> supercat writes:
>> > Since the functions were defined before the preprocessor became an
>> > essential part of the language, the names were limited to six characters;
>> > I think it might have been good to apply a looser constraint that all
>> > library functions must be *unique* in the first 6 characters, but I don't
>> > think fixed_ would be a particularly good name even then.
>> [...]
>> 
>> C90 required external names to be unique in the first 6 characters,
>> possibly ignoring case.  The C90 standard library had several
>> functions whose names are longer than 6 characters; vprintf, at 8
>> characters, is the longest I found in a quick search.
>
>> How is the preprocessor relevant?
>
> If implementations were allowed to regard external names starting with
> some character sequence as reserved, then the preprocessor could get
> around the 6-character limit for function names, by having an
> implementation assign a short implementation-specific external name for
> each library function.
>
> #define strcpy_with_pad _Q382x

So, a hypothetical solution for a problem that, as far as I can tell,
never existed, and certainly did not exist by the time of the 1989
ANSI C standard

[...]

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

#93595

On Thursday, September 15, 2016 at 7:20:59 PM UTC-5, Keith Thompson wrote:
> supercat writes:
> > If implementations were allowed to regard external names starting with
> > some character sequence as reserved, then the preprocessor could get
> > around the 6-character limit for function names, by having an
> > implementation assign a short implementation-specific external name for
> > each library function.
> >
> > #define strcpy_with_pad _Q382x
> 
> So, a hypothetical solution for a problem that, as far as I can tell,
> never existed, and certainly did not exist by the time of the 1989
> ANSI C standard

The issue did exist when the names of standard-library functions were being
established.  If the ability to use longer names in source than were attached
at link time had existed then, the length limit for linker names would not
have been an issue.

Further, the approach would still be useful even today to allow an
implementation to make additional library functions available to compilation
units that include header files for them.  If an implementation's library
included a function named "fred()", that would conflict with a user-code
identifier by the same name.  If, however, the library contained a function
called __qz_fred(), the implementation could bundle a header file <fred.h>
which with the line "#define fred __qz_fred".  User code that includes that
header would be unable to defined a "fred()" function, but code which does
not include that header would be free to do so.

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

#93618

luser droog <luser.droog@gmail.com> writes:

> On Thursday, September 15, 2016 at 2:32:39 PM UTC-5, Tim Rentsch wrote:
>> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>
>>
>>> Incidentally:  I went on a search for strncpy() in that kernel at
>>> one point;  out of something like 80ish call sites, only 4 were
>>> correct.
>>
>> The problem with strncpy() is not what functionality it provides
>> but the name used to provide it.  In retrospect I think it should
>> have been called something like strnotwhatyouexpectcpy().
>
> I suggest char_array_cpy() or fixed_field_cpy().  Maybe *fld*.

All of these (mine included) are stylistically at odds with other
standard library functions.  In light of that I withdraw my
previous strawman and offer strnwtf() as a possible replacement
(the last part being short for "write truncated field").

(I really hope no one is taking these suggestions seriously.)

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

#93619

On Friday, September 16, 2016 at 2:17:27 PM UTC+1, Tim Rentsch wrote:
>
> >> The problem with strncpy() is not what functionality it provides
> >> but the name used to provide it.  In retrospect I think it should
> >> have been called something like strnotwhatyouexpectcpy().
> >
> > I suggest char_array_cpy() or fixed_field_cpy().  Maybe *fld*.
> 
> All of these (mine included) are stylistically at odds with other
> standard library functions.  In light of that I withdraw my
> previous strawman and offer strnwtf() as a possible replacement
> (the last part being short for "write truncated field").
> 
> (I really hope no one is taking these suggestions seriously.)
>
Standardisation actually narrows the functionality available to the programmer,
until the standard sweeps the board and every non-conforming platform
becomes obsolete. That can take a long time.
You can't use the standard identifier because it will be available on some
systems and not on others. You can try conditional define guards, but you just
dig a hole for yourself going too far down that route - the conditionals keep
on breaking.
Now with isnan() we're really in trouble. We can't use the identifier isnan()
because it is in the process of standardisation, and we can't write it portably
as #define myisnan(x) ( (x)==(x) ? 0 : 1) because some compiler will optimise
out the "redundant" test.
But with a function to copy a string to a buffer, taking a length for safety,
just write one, call it mysafestrcpy(), make it static, and then supply it.

The trivial is important, and you can't have programs breaking just because
of a little string copying routine.  

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

#93635

On Friday, September 16, 2016 at 9:06:21 AM UTC-5, Malcolm McLean wrote:
> Now with isnan() we're really in trouble. We can't use the identifier isnan()
> because it is in the process of standardisation, and we can't write it portably
> as #define myisnan(x) ( (x)==(x) ? 0 : 1) because some compiler will optimise
> out the "redundant" test.

The solution would be to define a class of identifiers which are reserved
for future C standards *but* which user code will likely be authorized by
future C standards to use in certain ways on older implementations, with
the older implementations processing them according to natural semantics.

If the _CX prefix had been designated for that purpose, and if a future
standard were to promise that _CX_isnan() will be a macro that invokes an
intrinsic, then user code could safely start including

    #if !defined(_CX_isnan)
    #define _CX_isnan(x) user_isnan_implementation(x)
    #endif

Anyone who used the _CX prefix in a way which didn't end up getting
authorized by a future standard might be out of luck if a future standard
uses their identifier for some contrary purpose, but if compilers were
required to allow user-code definitions of macros they didn't otherwise
know about, user code could easily be written to taken advantage of features
on compilers that have them, but be just as useful on compilers that don't.

[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