[gens]

I don't understand why it is limited to 255 chars. The kernel copies the string(s) into the programs memory so it would be a kernel bug if the program got a non null-terminated or too long string.

More importantly this program has a bug in that it doesn't check if there is an argument passed to it at all.

Good effort but can improve a lot. I would praise the documentation but it is rather imprecise. All in all i wouldn't put it on the front page of HN yet.

[kelseyhightower]

This is great feedback, which I plan to use to improve the echo program. I'm just learning (on my own), and I figured I would just post my progress and I would get some feedback; it worked!

echo is far from finished, and it's safe to say "I don't know what the hell I'm doing", but hey, I gotta start somewhere.

[unixbhaskar]

That's the spirit Kelsey! keep it up.

[pavlov]

Maybe the 255-char limit is a feature? If this "fast echo" is meant to be used in a script that writes entries to a log where you wouldn't want long text anyway, or something like that... So having a known upper bound for the output size can be useful.

[cyphar]

> I don't understand why it is limited to 255 chars. The kernel copies the string(s) into the programs memory so it would be a kernel bug if the program got a non null-terminated or too long string.

But you can also pass arguments to execve(2) which are not null-terminated.

[gens]

The kernel copies the strings you pass in the array of pointers. (haven't checked though, but it is better then the alternative of not copying and dealing with the mess)

[cyphar]

The memory mapping is the same before and after execve(2), so I don't think it needs to be copied. I'll take a look though.

[gens]

Maybe only a few pages remain as programs don't inherit memory from their parents. It could be done for those strings but consider that mappings are in 4k pages (so the rest of the page would have to be cleared to 0).