Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: fread a file of unknown size Date: Mon, 09 Mar 2015 10:44:43 -0700 Organization: None to speak of Lines: 43 Message-ID: <87pp8i2hh0.fsf@kst-u.example.com> References: <87twxu2pew.fsf@kst-u.example.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="c77ff4d35e33d1c939d3461ebde8dd0d"; logging-data="10661"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/8sEYZVuLbXMx0d3u151vR" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:+EPax6hPvMZkhANEBTka9sxmNn4= sha1:l0++ZDYLTPTC0Af5odgdVdQvq2M= Xref: csiph.com comp.lang.c:58025 glen herrmannsfeldt writes: > Keith Thompson wrote: > (snip, I wrote) >>> Yes, but does the C standard allow for a file to reach EOF, and then, >>> on the next read, not be at EOF? > >> I don't think so, but fseek() clears the end-of-file indicator. > >>> I did once (OS/2 1.0 days) port gnu tail to OS/2, and it did work. >>> I didn't try very hard to figure out how it worked, just that it did. > >> I think tail (specifically `tail -f`) uses fseek(file, 0, SEEK_CUR). > > Okay, I was going to say that once fread() returned zero it would > keep doing that, but then I remembered tail. But then it was about 25 > years ago that I was looking at tail. I did remember wondering if > it would work the same way. > > The biggest problem I remember with gnu utilities is that they would > use 0 as an argument to a function expecting (char *). When I complained > to the gnu people, they had some comment about systems having different > sized (int) and (char*) not being supported. I don't suppose you have an example? If there's a visible prototype, passing 0 to a non-variadic function expecting a char* is not a problem. It will be implicitly converted to char*, and converting a constant 0 to a pointer type yields a null pointer. (Personally I'd use NULL or (char*)NULL just for the sake of clarity.) Passing 0 to a function expecting a char* either when there's no visible prototype, or when it corresponds to the ", ..." in a variadic function, does have undefined behavior. It can break if char* and int are of different sizes, if a null pointer is not represented as all-bits-zero, if int and char* are passed as arguments using different mechanisms, or for any other conceivable reason. -- 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"