there's no bad consequence from doing fread() on a FILE* that
may be NULL. The real problem is ignoring the return from fread,
suppose the file is too short for instance.
Bye.
Jasen
You are wrong, and I posted an example, here it is again:
PS,
you are probably confused with 'read()', read() accepts a fileno,
an integer, and if zero reads from stdin.
So this will always read from stdin:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
main()
{
char buffer[100];
size_t bytes_read;
bytes_read = read(0, buffer, 100);
fprintf(stderr, "bytes_read=%d\n", (int)bytes_read);
}
grml: ~ # gcc -o test3 test3.c
grml: ~ # ./test3
asfweaswerwerwerwerwerw
bytes_read=24
In case of read() there is an other problem, that the higher level 'fread()'
protected us from, and a frequent make mistake is not to call read() again if
it returns EAGAIN (and lose data), from libc.info:
- Function: ssize_t read (int FILEDES, void *BUFFER, size_t SIZE)
The ead' function reads up to SIZE bytes from the file with
descriptor FILEDES, storing the results in the BUFFER. (This is
not necessarily a character string, and no terminating null
character is added.)
The return value is the number of bytes actually read. This might
be less than SIZE; for example, if there aren't that many bytes
left in the file or if there aren't that many bytes immediately
available. The exact behavior depends on what kind of file it is.
Note that reading less than SIZE bytes is not an error.
A value of zero indicates end-of-file (except if the value of the
SIZE argument is also zero). This is not considered an error. If
you keep calling ead' while at end-of-file, it will keep
returning zero and doing nothing else.
If ead' returns at least one character, there is no way you can
tell whether end-of-file was reached. But if you did reach the
end, the next read will return zero.
In case of an error, ead' returns -1. The following rrno'
error conditions are defined for this function:
AGAIN'
Normally, when no input is immediately available, ead'
waits for some input. But if the NONBLOCK' flag is set
for the file (*note File Status Flags:
, ead' returns
immediately without reading any data, and reports this error.
*Compatibility Note:* Most versions of BSD Unix use a
different error code for this: WOULDBLOCK'. In the GNU
library, WOULDBLOCK' is an alias for AGAIN', so it
doesn't matter which name you use.
On some systems, reading a large amount of data from a
kernel cannot find enough physical memory to lock down the
user's pages. This is limited to devices that transfer with
direct memory access into the user's memory, which means it
does not include terminals, since they always use separate
buffers inside the kernel. This problem never happens in the
GNU system.
Any condition that could result in AGAIN' can instead
result in a successful ead' which returns fewer bytes than
requested. Calling ead' again immediately would result in
AGAIN'.
BADF'
The FILEDES argument is not a valid file descriptor, or is
not open for reading.
INTR'
ead' was interrupted by a signal while it was waiting for
input. *Note Interrupted Primitives::. A signal will not
necessary cause ead' to return INTR'; it may instead
result in a successful ead' which returns fewer bytes than
requested.
IO'
For many devices, and for disk files, this error code
indicates a hardware error.
IO' also occurs when a background process tries to read
from the controlling terminal, and the normal action of
stopping the process by sending it a IGTTIN' signal isn't
working. This might happen if the signal is being blocked or
ignored, or because the process group is orphaned. *Note Job
Control::, for more information about job control, and *Note
Signal Handling::, for information about signals.
Please note that there is no function named ead64'. This is not
necessary since this function does not directly modify or handle
the possibly wide file offset. Since the kernel handles this state
internally, the ead' function can be used for all cases.
This function is a cancellation point in multi-threaded programs.
This is a problem if the thread allocates some resources (like
memory, file descriptors, semaphores or whatever) at the time
ead' is called. If the thread gets cancelled these resources
stay allocated until the program ends. To avoid this, calls to
ead' should be protected using cancellation handlers.
The ead' function is the underlying primitive for all of the
functions that read from streams, such as getc'.
This is a bit out of context for these newsgroups, and more for
comp dot os dot linux dot development dot apps and related.
