3 ms·

But how do you left pad a string?

• deleted 1y ago
  [deleted]
• 1718627440 1y 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.
  • brabel 1y 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?
    • lionkor 1y ago
      strdup allocates https://en.cppreference.com/w/c/experimental/dynamic/strdup https://en.cppreference.com/w/c/experimental/dynamic/strdup
      • brabel 1y 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.
        • 1718627440 1y 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.
    • 1718627440 1y 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.
  • newsoftheday 1y ago
    strndup would be safer if I correctly recall from my C days?
    • 1718627440 1y 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.
• kidmin 1y ago
  snprintf(buf, bufsize, "%*s", padwidth, str)?