Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: How to read a data file whose size is unknown in C? Date: Fri, 14 Aug 2015 08:57:32 -0700 Organization: None to speak of Lines: 75 Message-ID: References: <7b7a215a-b72a-48ba-bbdc-ddc22ad8c5b7@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="10631"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19pOVMMjKCJ3LVblz9Y0QNW" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:GlvjV8Zrht8ymbJXkjcK6AfYigw= sha1:bsJRYZxDjKZcvJhJe/ByYWyeHQQ= Xref: csiph.com comp.lang.c:67398 Bartc writes: [...] >> To me, input from pipes is the main reason not to use other >> counting methods. > > I don't know anything about pipes. Perhaps you should learn. > Does fopen() return a handle to a > pipe? It can. Unix-like systems have *named pipes*, which have directory entries like ordinary files and can be opened by fopen(). The POSIX popen() function returns a FILE* referring to a pipe. The pipe() system call creates a pipe and gives you a pair of file descriptors (not FILE*s) referring to it. You can use fdopen() to get a FILE* from a file descriptor, and fileno() to get a file descriptor from a FILE*. And it's very common for stdin, stdout, and/or stderr to refer to a pipe. From a program's point of view, the main difference between a FILE* referring to a pipe and a FILE* referring to an ordinary file is that fseek() and ftell() don't work on pipes (and they cleanly report an error if you call them). [...] > Someone mentioned the OP is trying to read or load an image file. Well > I'm looking the details of a jpg file right now: it's 355436 bytes in > length, it hasn't been updated since 2006, and is located on my random > access hard drive within a Windows file system (probably NTFS). > > Any reason why C's fseek and ftell functions shouldn't work on this > file? Not just to establish the size, but to be able to do random access > or to find out which offset in the file is going to be read on the next > fgetc(). No reason that I can think of -- assuming you access it as a file. But consider this. I have a jpg image file on my computer called "albatross.jpg". The "display" command, part of ImageMagick, displays an image on my screen. This command works: display albatross.jpg So does this: cat albatross.jpg | display (Normally that would be "display < albatross.jpg", but I wanted to show the use of pipes clearly.) I've mentioned elsewhere that "view /proc/stat" works, even though /proc/stat is a pseudo-file for which the OS reports a size of 0. On the other hand, if it's convenient to write a program that only works if a given stream is seekable that's fine. Working correctly on pipes can be convenient for users, but it's not mandatory. > (Actually I'm surprised that fseek and ftell haven't been deprecated > since they are apparently so completely useless according to the > opinions here!) Nobody has been saying that. We've merely been pointing out that using fseek and ftell to determine the size of a file is not 100% reliable, and that if a program is already using system-specific functions, it might as well use them to determine the size of a file if it needs to. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"