Re: Programming in standard c


"Eric Sosman" <esosman@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:kMudnegkVfFhnOjanZ2dnUVZ_sSlnZ2d@xxxxxxxxxxxxxx
Richard wrote:

Rubbish. All files have a byte size.

How many bytes does /dev/tty hold? How about /dev/zero?
/dev/ptyp0? /dev/random? /dev/poll? CON:? LPT:?
....
And even for an ordinary file whose length can be known,
many systems permit the length to change between the moment
it's queried and the moment the result is used. How many bytes
should you allocate for an in-memory copy of /var/adm/messages?

These are all very interesting examples which should be kept in mind when
writing mission-critical code or code for life-support systems.

But there is a distinct class of well-behaved files (input files of a
compiler for example), which are unlikely to be huge and unlikely to change.
For a lot of applications and their files, this will be the case.

With shared files on multi-user/multi-process systems there can be pitfalls,
but size of the file suddenly changing would be the least of the problems.

I don't know how to deal with /var/adm/messages or similar. Suppose I read
byte-by-byte as recommended then someone updates the beginning of the file?
Maybe it's foolhardy to even attempt making a copy of such a file. I'm not
allowed to lock it because that's also frowned upon. What exactly can one do
with such a file?


Bart


.