Re: The semantics of `truncate'.

[Toon Moene <toon at moene dot indiv dot nluug dot nl>]

"Kaveh R. Ghazi" wrote:

>  > One of the reasons for this could be that the file is open while
>  > truncate is being called - would this be a problem ?
> 
> Yes I think so.  Truncate is implemented in glibc by calling open &
> ftruncate.  You then have two file descriptors and depending on which
> gets flushed/sync'ed there may be problems.
> 
> I would try calling fflush(stream)/ftruncate(fileno(stream)) where
> "stream" is the open FILE* on the file in question.

Thanks - can I assume `fileno' exists ?  Or do I have to configure-test
for both `ftruncate' and `fileno' ?

>  > --- 2,9 ----
>  >   #include "fio.h"
>  >
>  > + #ifdef HAVE_TRUNCATE
>  > + #include <unistd.h>
>  > + #endif /* defined(HAVE_TRUNCATE) */
>  > +
> 
> Please don't do this.  Either include unistd.h unconditionally, (gcc
> fixproto guarantees that it exists and libf2c is a target lib) or
> check/test HAVE_UNISTD_H.

OK - thanks for the heads up.  I'm glad someone who actually knows how
this stuff works is willing to look over my shoulder :-)

> It might also be a good time to remove the KR_headers stuff, since
> libf2c is only compiled by gcc now.

I agree that it isn't necessary.  However, keeping this stuff makes the
diffs with the original libf2c smaller and my task when merging much
simpler.

Thanks,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)