3 ms·

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

by gens 10y ago

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.

pavlov 10y ago
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.
- deleted 10y ago
  [deleted]
cyphar 10y ago
> 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 10y ago
  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 10y ago
    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 10y ago
      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).
kelseyhightower 10y ago
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 10y ago
  That's the spirit Kelsey! keep it up.

by gens 10y ago

pavlov 10y ago

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.

deleted 10y ago
[deleted]

cyphar 10y ago

> 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 10y ago
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 10y ago
  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 10y ago
    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).

kelseyhightower 10y ago

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 10y ago
That's the spirit Kelsey! keep it up.