And gasoline just magically appears at the gas station? Wars over oil are being fought for decades and nothing similar has happened over Lithium yet?

On the other hand, a human can only look into one direction, while a Tesla can look into all directions at once. Also human drivers are often distracted, intoxicated, etc. An attentive driver would probably perform better, but I’d rather have all others be slightly worse on the high end of driving skill, while significantly increasing the skill of low end drivers.

> a human can only look into one direction, while a Tesla can look into all directions at once.

Human visual targeting happens extremely quickly relative to the rate of change of objects on the road, so this isn't very important. If it were, attentive driver crashes would happen far more often than they do.

> Also human drivers are often distracted, intoxicated, etc.

This says nothing about the capability of the system. Tesla's have their own non-camera-related failure modes too, like not knowing that traffic lights don't move with the vehicle through space, like changing lanes into opposite-direction lanes, like not having object permanence, like needing to recognize what an object is before deciding to not run it over.

But now also imagine if human drivers were in serious need of glasses but weren't wearing them.

Santa Claus

There are many forms of pasta that don’t have this problem.

As a German I envy your meetings with Germans

The gpu can’t access that directly however. On Apple Silicon it can all be used as vram.

This approach sounds like a great way to get a lot of security holes into your code. Maybe your competitors will be faster at first, but it’s probably better to be a bit slower and not leaking all your users data.

I'm mostly thinking about the frontend.

If I had a backend API that was serving user data, I'd of course check more carefully.

This kind of mistake always seemed amateurish to me.

Fair enough. I would still personally feel uneasy about it, but I guess it’s alright if it works for others.

Can’t wait for the "falsehoods programmers believe about buildings" blog post

But how do you left pad a string?

    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.

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?

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

strdup allocates

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

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.

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.

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

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.

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