Re: read() builtin doesn't read integer value /proc files (but bash's does)

[Steve Schnepp <steve.schnepp@xxxxxxxxx>]

2010/9/2 Jilles Tjoelker <jilles@xxxxxxxx>:

Thanks for your prompt reply.

> Note that a change in the file between the single-byte reads will cause
> an inconsistent value to be read. This is also the case with regular
> files on a filesystem, so it is acceptable.

Are you implying that:
- if the procfs is made to support char per char reads, dash reading
an inconsistent value is actually a feature ?
- buffering should, therefore, always be explicit ?

On a side note, the whole procfs seems to be designed around one
unique page read if possible (1x 4K).
I think it does so in order to be able to vastly simplify its
usage/implementation by kernel modules.

> If single-byte reads are really unacceptable, then the proper way to
> read these files needs to be documented, and clear violations that will
> not work properly should cause an error (in this case, this means that
> reading one byte from offset 0 should fail like reading one byte from
> offset 1 does).

+1 for "the proper way to read these files needs to be documented" and
I also think that emitting an error would be better than silently
returning erroneous data. [ EOVERFLOW is coming to my mind ]

--
Steve Schnepp
http://blog.pwkf.org/
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html