1718627440 5 days ago

    char * 
    left_pad (const char * string, unsigned int pad)
    {
        char tmp[strlen (string)+pad+1];
        memset (tmp, ' ', pad);
        strcpy (tmp+pad, string);
        return strdup (tmp);
    }
Doesn't sound too hard in my opinion. This only works for strings, that fit on the stack, so if you want to make it robust, you should check for the string size. It (like everything in C) can of course fail. Also it is a quite naive implementation, since it calculates the string size three times.
Reply View 7 replies
  • brabel 5 days ago

    Not a C expert but you’re using a dynamic array right on the stack, and then returning the duplicate of that. Shouldn’t that be Malloc’ed instead?? Is it safe to return the duplicate of a stack allocated array, wouldn’t the copy be heap allocated anyway? Not to mention it blows the stack and you get segmentation fault?

    Reply View 4 replies
    • 1718627440 5 days ago

      > and then returning the duplicate of that. Shouldn’t that be Malloc’ed instead??

      Like the sibling already wrote, that's what strdup does.

      > Is it safe to return the duplicate of a stack allocated

      Yeah sure, it's a copy.

      > wouldn’t the copy be heap allocated anyway?

      Yes. I wouldn't commit it like that, it is a naive implementation. But honestly I wouldn't commit leftpad at all, it doesn't sound like a sensible abstraction boundary to me.

      > Not to mention it blows the stack and you get segmentation fault?

      Yes and I already mentioned that in my comment.

      ---

      > dynamic array right on the stack

      Nitpick: It's a variable length array and it is auto allocated. Dynamic allocation refers to the heap or something similar, not already done by the compiler.

      Reply View 0 replies
    • lionkor 5 days ago

      strdup allocates

      https://en.cppreference.com/w/c/experimental/dynamic/strdup

      Reply View 2 replies
      • brabel 4 days ago

        My point was that if you’re going to allocate anyway what was the point of allocating the original on the stack? You wouldn’t need the duplicate if you malloc that.

        Reply View 1 reply
        • 1718627440 4 days ago

          Yes, that is right. The only reason I did it this way was, because I wanted to demonstrate a naive implementation, I wouldn't commit that, but I wouldn't commit leftpad at all.

          Allocating on the stack is pretty cheap, it's only a single instruction to move the stack pointer. The compiler is likely to optimize it away completely. When doing more complicated things, where you don't build the string linearly allocating on the stack first can be likely cheaper, since the stack memory is likely in cache, but a new allocation isn't. It can also make the code easier, since you can first do random stuff on the stack and then allocate on the heap once the string is complete and you know its final size.

          Reply View 0 replies
  • newsoftheday 5 days ago

    strndup would be safer if I correctly recall from my C days?

    Reply View 1 reply
    • 1718627440 5 days ago

      Safer for what? That opinion seems to be misguided to me.

      strndup prevents you from overrunning the allocation of a string given that you pass it the containing allocations size correctly. But if you got passed something that is not a string, there will be a buffer overrun right there in the first line. Also what outer allocation?

      You use strcpy when you get a string and memcpy when you get an array of char. strncpy is for when you get something that is maybe a string, but also a limited array. There ARE use cases for it, but it isn't for safety.

      Reply View 0 replies
kidmin 5 days ago

snprintf(buf, bufsize, "%*s", padwidth, str)?

Reply View 0 replies