Comment by 1718627440

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

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