Reply to thread

Message: [QUOTE="jacob navia, post: 3195405"] er... YES! We could restrict this to normal files. I just can't imagine a file system that doesn't provide a way of knowing the length of a file. Maybe there is SOMEWHERE in the world a crazy file system like that but why should we care about it? Much simpler would be if we had size_t filesize(FILE *); isn't it? I.e. the standard would abstract away from the programmer all the details of how to do this quite ELEMENTARY operation! If there are file systems where there is no way to know that besides by reading the whole file, then THOSE SYSTEMS would be forced to do that not everyone! THAT could be left to the implementation of "filesize" and we could rely on a portable way of doing that. The objective of this message is precisely to point to the lack of functionality in the standard library. I *had* to do this since there is NOW no guarantee that the lower level functions do this. I was programming around a limitation of standard C. I do not understand why the committee ignores all the work done by POSIX and incorporates their error analysis into standard C for the low level functions like fread/fopen, etc. Why refusing to do a more sophisticated error analysis than just testing for NULL? I cite the standard for the fopen function: Returns The fopen function returns a pointer to the object controlling the stream. If the open operation fails, fopen returns a null pointer. Not a SINGLE WORD of error analysis more sophisticated than "it failed". This is really level ZERO of error analysis. [/QUOTE]

Verification