Re: Silly newbie question - Caret character (^)

Discussion in 'C Programming' started by Seebs, Nov 11, 2010.

  1. Seebs

    Seebs Guest

    (Note followups, this has stopped being very Pythony.)

    On 2010-11-11, Lawrence D'Oliveiro <_zealand> wrote:
    > Another function that should be deprecated is strncat???I myself was caught
    > out misunderstanding it recently. What purpose does it serve?


    I'm wondering if you're thinking of strncpy(), which is the famously bogus
    one. strncat() just has a fencepost error -- given a limit N, it will
    write at most N+1 characters. strncpy(), however, pads with null bytes
    if the source string isn't long enough, and does not null terminate if there
    isn't room to.

    This behavior is nearly always undesireable. However, if you were building
    a filesystem in which file path names were given exactly sixteen bytes of
    space in the directory entry, and you didn't want to truncate them to 15
    bytes, you might write precisely this behavior. So that's what we got.

    I don't know whether anyone's gotten buy-in from the standards people
    for strlcpy()/strlcat(), but I really hope so. Me, I just use
    snprintf with a %s format instead of str*cpy().

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
    Seebs, Nov 11, 2010
    #1
    1. Advertising

  2. > Lawrence D'Oliveiro <_zealand> wrote:
    > > Another function that should be deprecated is strncat???
    > > I myself was caught out misunderstanding it recently.
    > > What purpose does it serve?


    Like strtok, it serves a niche purpose that doesn't come up as
    often as people might think.

    Seebs <> wrote:
    > I'm wondering if you're thinking of strncpy(),
    > which is the famously bogus one.


    Yet it's actually strncat that is the odd one out of the trio...

    strncat(p, q, n) - p is string, q is array
    strncmp(p, q, n) - p is array, q is array
    strncpy(p, q, n) - p is array, q is array

    If they were prefixed memn, instead of strn, then I'm reasonably
    sure there would be fewer complaints and surprises with strncpy.

    The problem with strncpy is not that it pads with zero or won't
    terminate a full array. The problem is that it doesn't let you
    choose the pad character.

    --
    Peter
    Peter Nilsson, Nov 11, 2010
    #2
    1. Advertising

  3. Seebs

    Ben Pfaff Guest

    Peter Nilsson <> writes:

    > The problem with strncpy is not that it pads with zero or won't
    > terminate a full array. The problem is that it doesn't let you
    > choose the pad character.


    It's not really strncpy's fault, but in my experience the biggest
    problems with strncpy are that people don't understand what it
    does. Some people expect it to always null-terminate; other
    people don't realize that how expensive it is to copy a short
    string into a large buffer with strncpy(). (I once made a
    program much faster by using a function other than strncpy() to
    copy a usually short file name into a 4096-byte buffer.)
    --
    Ben Pfaff
    http://benpfaff.org
    Ben Pfaff, Nov 11, 2010
    #3
  4. In message <>, Seebs wrote:

    > (Note followups, this has stopped being very Pythony.)
    >
    > On 2010-11-11, Lawrence D'Oliveiro <_zealand>
    > wrote:
    >
    >> Another function that should be deprecated is strncat???I myself was
    >> caught out misunderstanding it recently. What purpose does it serve?

    >
    > I'm wondering if you're thinking of strncpy(), which is the famously bogus
    > one.


    I don’t see what’s bogus about that. From my Linux man page:

    char *strncpy(char *dest, const char *src, size_t n);

    The strncpy() function is similar, except that at most n bytes of
    src are copied. Warning: If there is no null byte among the first n
    bytes of src, the string placed in dest will not be null-terminated.

    That seems straightforward enough: n is the size of dest. The problem with
    strncat is that the size limit controls how much of the _source_ string will
    be copied, it says nothing about the maximum size of the _destination_
    buffer. To me, that makes no sense.

    Of course, it goes without saying that strcat and strcpy should be encased
    in concrete overshoes and dropped off a pier somewhere...

    > I don't know whether anyone's gotten buy-in from the standards people
    > for strlcpy()/strlcat(), but I really hope so.


    They do seem like much more sensible functions. Though personally I would
    rather do away with null-terminated strings.

    > Me, I just use snprintf with a %s format instead of str*cpy().


    That’s an idea I should think about. :)
    Lawrence D'Oliveiro, Nov 11, 2010
    #4
  5. Seebs

    Mark Wooding Guest

    Lawrence D'Oliveiro <_zealand> writes:

    > I don’t see what’s bogus about that. From my Linux man page:
    >
    > char *strncpy(char *dest, const char *src, size_t n);
    >
    > The strncpy() function is similar, except that at most n bytes of
    > src are copied. Warning: If there is no null byte among the first n
    > bytes of src, the string placed in dest will not be null-terminated.
    >
    > That seems straightforward enough: n is the size of dest.


    You snipped the bizarre bit:

    If the length of src is less than n, strncpy() pads the remainder
    of dest with null bytes.

    Basically, it means `fill this here buffer with string stuff from there,
    padding with zeroes if there wasn't enough string'. It's what you
    wanted for filling in tar headers and suchlike, but not for writing safe
    string handling.

    > > I don't know whether anyone's gotten buy-in from the standards people
    > > for strlcpy()/strlcat(), but I really hope so.

    >
    > They do seem like much more sensible functions. Though personally I
    > would rather do away with null-terminated strings.


    That's trickier because they're part of the language proper (string
    literals are null terminated and include the terminator in their sizes)
    and wired throughout too many operating system interfaces.

    > > Me, I just use snprintf with a %s format instead of str*cpy().

    >
    > That’s an idea I should think about. :)


    I use a simple dynamic string library for more or less everything. It
    doesn't try to do everything, but it does do simple concatenation and
    formatting, and it /doesn't/ prevent you getting at the underlying
    characters if there's something it missed.

    -- [mdw]
    Mark Wooding, Nov 11, 2010
    #5
  6. Seebs

    Seebs Guest

    On 2010-11-11, Lawrence D'Oliveiro <_zealand> wrote:
    >> I'm wondering if you're thinking of strncpy(), which is the famously bogus
    >> one.


    > I don???t see what???s bogus about that.


    The combination of padding and possibly not null-terminating.

    > That seems straightforward enough: n is the size of dest. The problem with
    > strncat is that the size limit controls how much of the _source_ string will
    > be copied, it says nothing about the maximum size of the _destination_
    > buffer. To me, that makes no sense.


    Wow. You know, I'd never thought about that. I always did it by using
    information about the destination to pick n, but that's just evidence that
    it's so broken I've always had to work around it. :)

    > They do seem like much more sensible functions. Though personally I would
    > rather do away with null-terminated strings.


    In higher level languages, sure. In C, they have a lot of advantages that
    have made them a useful format. Mostly.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
    Seebs, Nov 11, 2010
    #6
  7. Seebs

    Roy Smith Guest

    In article <>,
    Seebs <> wrote:

    > This behavior is nearly always undesireable. However, if you were building
    > a filesystem in which file path names were given exactly sixteen bytes of
    > space in the directory entry, and you didn't want to truncate them to 15
    > bytes, you might write precisely this behavior.


    Well, 14 actually, not 16. The last two bytes were for the inode number.
    Roy Smith, Nov 12, 2010
    #7
  8. Seebs

    Seebs Guest

    On 2010-11-12, Roy Smith <> wrote:
    > In article <>,
    > Seebs <> wrote:
    >> This behavior is nearly always undesireable. However, if you were building
    >> a filesystem in which file path names were given exactly sixteen bytes of
    >> space in the directory entry, and you didn't want to truncate them to 15
    >> bytes, you might write precisely this behavior.


    > Well, 14 actually, not 16. The last two bytes were for the inode number.


    Agh. I even knew that, and then I thought "no, I'm sure there was a 16
    in there somewhere".

    .... And yes, I'm this bad at pretty much everything to do with remembering
    details. I have learned to live my life in terms of reference materials.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
    Seebs, Nov 12, 2010
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?RGF2aWQrKw==?=

    Silly newbie question.

    =?Utf-8?B?RGF2aWQrKw==?=, Nov 15, 2005, in forum: ASP .Net
    Replies:
    7
    Views:
    408
    Alan Silver
    Nov 21, 2005
  2. Replies:
    3
    Views:
    283
  3. Philip Semanchuk
    Replies:
    58
    Views:
    1,287
    Seebs
    Nov 11, 2010
  4. Noah
    Replies:
    3
    Views:
    125
    Marek Mand
    Mar 5, 2004
  5. Bart Vandewoestyne
    Replies:
    8
    Views:
    689
    Bart Vandewoestyne
    Sep 25, 2012
Loading...

Share This Page