Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #28134 > unrolled thread

Strange Behaviour in finding Size of a File

Back to article view | Back to comp.lang.c

Contents

  Strange Behaviour in finding Size of a File felix <ckpradip@gmail.com> - 2012-11-08 23:09 -0800
    Re: Strange Behaviour in finding Size of a File "Where's all the China Blue food?" <chine.bleu@yahoo.com> - 2012-11-08 23:26 -0800
    Re: Strange Behaviour in finding Size of a File James Kuyper <jameskuyper@verizon.net> - 2012-11-09 06:56 -0500
      Re: Strange Behaviour in finding Size of a File felix <ckpradip@gmail.com> - 2012-11-12 22:23 -0800
        Re: Strange Behaviour in finding Size of a File James Kuyper <jameskuyper@verizon.net> - 2012-11-13 07:27 -0500
          Re: Strange Behaviour in finding Size of a File felix <ckpradip@gmail.com> - 2012-11-19 01:52 -0800
            Re: Strange Behaviour in finding Size of a File James Kuyper <jameskuyper@verizon.net> - 2012-11-19 08:09 -0500
    Re: Strange Behaviour in finding Size of a File Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-09 08:24 -0500
      Re: Strange Behaviour in finding Size of a File Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-11-10 06:06 -0800
        Re: Strange Behaviour in finding Size of a File Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-10 15:12 +0000
          Re: Strange Behaviour in finding Size of a File Ian Collins <ian-news@hotmail.com> - 2012-11-11 08:40 +1300
            Re: Strange Behaviour in finding Size of a File Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-10 20:36 +0000
        Re: Strange Behaviour in finding Size of a File Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-10 10:13 -0500
    Re: Strange Behaviour in finding Size of a File John Gordon <gordon@panix.com> - 2012-11-09 15:16 +0000
      Re: Strange Behaviour in finding Size of a File Mark Bluemel <mark_bluemel@pobox.com> - 2012-11-09 15:56 +0000
      Re: Strange Behaviour in finding Size of a File James Kuyper <jameskuyper@verizon.net> - 2012-11-09 11:01 -0500
    Re: Strange Behaviour in finding Size of a File Greg Martin <greg@softsprocket.com> - 2012-11-09 08:59 -0800
    Re: Strange Behaviour in finding Size of a File Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2012-11-09 19:42 +0100
      Re: Strange Behaviour in finding Size of a File Keith Thompson <kst-u@mib.org> - 2012-11-09 11:29 -0800
        Re: Strange Behaviour in finding Size of a File Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2012-11-09 20:47 +0100
          Re: Strange Behaviour in finding Size of a File Keith Thompson <kst-u@mib.org> - 2012-11-09 12:33 -0800
            Re: Strange Behaviour in finding Size of a File Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2012-11-10 02:08 +0100
              Re: Strange Behaviour in finding Size of a File Philip Lantz <prl@canterey.us> - 2012-11-09 18:33 -0800
                Re: Strange Behaviour in finding Size of a File gazelle@shell.xmission.com (Kenny McCormack) - 2012-11-10 02:58 +0000
                  Re: Strange Behaviour in finding Size of a File Philip Lantz <prl@canterey.us> - 2012-11-09 23:29 -0800
                    Re: Strange Behaviour in finding Size of a File Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-11-10 06:09 -0800
              Re: Strange Behaviour in finding Size of a File Ian Collins <ian-news@hotmail.com> - 2012-11-10 17:46 +1300
                Re: Strange Behaviour in finding Size of a File James Kuyper <jameskuyper@verizon.net> - 2012-11-10 22:20 -0500
                Re: Strange Behaviour in finding Size of a File Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-11-12 14:01 +0200
              Re: Strange Behaviour in finding Size of a File gazelle@shell.xmission.com (Kenny McCormack) - 2012-11-10 22:01 +0000
            Re: Strange Behaviour in finding Size of a File James Kuyper <jameskuyper@verizon.net> - 2012-11-09 22:14 -0500
              Re: Strange Behaviour in finding Size of a File Keith Thompson <kst-u@mib.org> - 2012-11-09 19:24 -0800
                Re: Strange Behaviour in finding Size of a File James Kuyper <jameskuyper@verizon.net> - 2012-11-09 23:30 -0500
                Re: Strange Behaviour in finding Size of a File Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-10 08:32 -0500
                  Re: Strange Behaviour in finding Size of a File Ike Naar <ike@sverige.freeshell.org> - 2012-11-10 17:42 +0000
                    Re: Strange Behaviour in finding Size of a File Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-10 15:19 -0500
    Re: Strange Behaviour in finding Size of a File Keith Thompson <kst-u@mib.org> - 2012-11-09 11:34 -0800

Page 1 of 2  [1] 2  Next page →

#28134 — Strange Behaviour in finding Size of a File

This method was written to create new Log File, when the size of the Log File reaches a max size defined by user [10MB in our case]. Here is the code snippet that does this check:

//-- Code starts here : --

static size_t LogSize = 1048576;
bool CreateNewLogs = false;


if ( stat ( logFile, &results ) == 0 )
{
	if ( results.st_size > LogSize )
	{
		CreateNewLogs = true;
	}
}
//-- Code ends here   : --

It is strange that the condition got satisfied when results.st_size = 2589116.
And we are sure that the size of the data that is written is between 50 to 100 bytes in one operation. And this check is done before writing into the LogFile.

I am not sure if I am missing anything in our understanding of the stat function. Any inputs or pointers on this regard will be really Helpful.


Thanks in advance, and please let me know if any other information is required.


--
Felix

[toc] | [next] | [standalone]

#28135

In article <8439d649-fae9-4828-8a86-d0c7c8489aa5@googlegroups.com>,
 felix <ckpradip@gmail.com> wrote:

> This method was written to create new Log File, when the size of the Log File 
> reaches a max size defined by user [10MB in our case]. Here is the code 
> snippet that does this check:
> 
> //-- Code starts here : --
> 
> static size_t LogSize = 1048576;

Is that actually 1 million, or 10485760?

> I am not sure if I am missing anything in our understanding of the stat 
> function. Any inputs or pointers on this regard will be really Helpful.

Are you making sure all output is flushed to disk before the stat? Stat does not 
include any bufferred output.

-- 
My name is Indigo Montoya. \\        Annoying Usenet one post at a time.
You flamed my father.       \'         At least I can stay in character.
Prepare to be spanked.     //               When you look into the void,
Stop posting that!        `/  the void looks into you, and fulfills you.

[toc] | [prev] | [next] | [standalone]

#28136

On 11/09/2012 02:09 AM, felix wrote:
> This method was written to create new Log File, when the size of the Log File reaches a max size defined by user [10MB in our case]. Here is the code snippet that does this check:
> 
> //-- Code starts here : --
> 
> static size_t LogSize = 1048576;
> bool CreateNewLogs = false;
> 
> 
> if ( stat ( logFile, &results ) == 0 )

That is presumably the POSIX stat() function, or something similar? If
so, its behavior is defined by the POSIX standard, not the C standard,
and you'll get better answers to your questions in comp.unix.programmer
than in this newsgroup.

> {
> 	if ( results.st_size > LogSize )
> 	{
> 		CreateNewLogs = true;
> 	}
> }
> //-- Code ends here   : --
> 
> It is strange that the condition got satisfied when results.st_size = 2589116.
> And we are sure that the size of the data that is written is between 50 to 100 bytes in one operation. And this check is done before writing into the LogFile.

Keep in mind that file I/O is normally buffered, so the buffer size is
more relevant than the size of your individual writes. Still, that seems
to be a rather large jump to explain by buffering.

> I am not sure if I am missing anything in our understanding of the stat function. Any inputs or pointers on this regard will be really Helpful.

The people in comp.unix.programming may need to know more details about
how data is written to the file, and whether or not you've used any
POSIX functions to change the file mode.
Just to get a better idea of what's going on, I'd recommend reporting
the file size somewhere (probably in a separate log file) every time you
call stat().
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#28243

On Friday, 9 November 2012 17:26:28 UTC+5:30, James Kuyper  wrote:
> On 11/09/2012 02:09 AM, felix wrote:
> 
> > This method was written to create new Log File, when the size of the Log File reaches a max size defined by user [10MB in our case]. Here is the code snippet that does this check:
> 
> > 
> 
> > //-- Code starts here : --
> 
> > 
> 
> > static size_t LogSize = 1048576;
> 
> > bool CreateNewLogs = false;
> 
> > 
> 
> > 
> 
> > if ( stat ( logFile, &results ) == 0 )
> 
> 
> 
> That is presumably the POSIX stat() function, or something similar? If
> 
> so, its behavior is defined by the POSIX standard, not the C standard,
> 
> and you'll get better answers to your questions in comp.unix.programmer
> 
> than in this newsgroup.
> 
> 
> 
> > {
> 
> > 	if ( results.st_size > LogSize )
> 
> > 	{
> 
> > 		CreateNewLogs = true;
> 
> > 	}
> 
> > }
> 
> > //-- Code ends here   : --
> 
> > 
> 
> > It is strange that the condition got satisfied when results.st_size = 2589116.
> 
> > And we are sure that the size of the data that is written is between 50 to 100 bytes in one operation. And this check is done before writing into the LogFile.
> 
> 
> 
> Keep in mind that file I/O is normally buffered, so the buffer size is
> 
> more relevant than the size of your individual writes. Still, that seems
> 
> to be a rather large jump to explain by buffering.
> 
> 
> 
> > I am not sure if I am missing anything in our understanding of the stat function. Any inputs or pointers on this regard will be really Helpful.
> 
> 
> 
> The people in comp.unix.programming may need to know more details about
> 
> how data is written to the file, and whether or not you've used any
> 
> POSIX functions to change the file mode.
> 
> Just to get a better idea of what's going on, I'd recommend reporting
> 
> the file size somewhere (probably in a separate log file) every time you
> 
> call stat().
> 
> -- 
> 
> James Kuyper


Thanks a Lot James and all others that helped me understand this problem.

As said above, the file I/O is buffered. The file size was not getting updated after each fwrite(). We tried to fflush() the after writing the data into log files. And now we see the correct size of the file.

We are trying to understand ftell()/fseek() also as suggested.

And thanks for suggestions regarding the constant - LogSize.

--
Felix

[toc] | [prev] | [next] | [standalone]

#28245

On 11/13/2012 01:23 AM, felix wrote:
> On Friday, 9 November 2012 17:26:28 UTC+5:30, James Kuyper  wrote:
...
> As said above, the file I/O is buffered. The file size was not
> getting updated after each fwrite(). We tried to fflush() the after
> writing the data into log files. And now we see the correct size of
> the file.

Note: the size that you saw before was also the correct size. That is -
it was the actual size currently taken up by the file on disk. It didn't
include the part that was still in the buffers, and had not yet been
written to the disk (that explanation is somewhat incomplete, but it's
good enough for this context). That might not have been the quantity you
wanted to know, but that doesn't make it incorrect.

> We are trying to understand ftell()/fseek() also as suggested.

If fflush() caused stat() to give you the size that you wanted, calling
ftell() is almost certainly a more efficient way of getting that size
information - at least if you can call it from within the same program
that's writing to the log file. According to the C standard, this is
only guaranteed if the file is opened in binary mode, but your use of
stat() suggests that you may be using a Unix-like system, in which case
text mode is indistinguishable from binary mode.

Your wording implies that you're having trouble understand ftell(). Can
you explain the nature of your confusion?
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#28379

On Tuesday, 13 November 2012 17:57:25 UTC+5:30, James Kuyper  wrote:
> On 11/13/2012 01:23 AM, felix wrote:
> 
> > On Friday, 9 November 2012 17:26:28 UTC+5:30, James Kuyper  wrote:
> 
> ...
> 
> > As said above, the file I/O is buffered. The file size was not
> 
> > getting updated after each fwrite(). We tried to fflush() the after
> 
> > writing the data into log files. And now we see the correct size of
> 
> > the file.
> 
> 
> 
> Note: the size that you saw before was also the correct size. That is -
> 
> it was the actual size currently taken up by the file on disk. It didn't
> 
> include the part that was still in the buffers, and had not yet been
> 
> written to the disk (that explanation is somewhat incomplete, but it's
> 
> good enough for this context). That might not have been the quantity you
> 
> wanted to know, but that doesn't make it incorrect.
> 
> 
> 
> > We are trying to understand ftell()/fseek() also as suggested.
> 
> 
> 
> If fflush() caused stat() to give you the size that you wanted, calling
> 
> ftell() is almost certainly a more efficient way of getting that size
> 
> information - at least if you can call it from within the same program
> 
> that's writing to the log file. According to the C standard, this is
> 
> only guaranteed if the file is opened in binary mode, but your use of
> 
> stat() suggests that you may be using a Unix-like system, in which case
> 
> text mode is indistinguishable from binary mode.
> 
> 
> 
> Your wording implies that you're having trouble understand ftell(). Can
> 
> you explain the nature of your confusion?
> 
> -- 
> 
> James Kuyper

First, Sorry for this delay in my response.

James, you did explain the information that we were looking for.
We were trying to understand which of those subroutines (ftell(3) or fflush(3)) would be more effective when used within the code. We wanted to make sure that we knew why we are using what we are using.

Once again, thank you James.

Thanks and Regards,
Felix

[toc] | [prev] | [next] | [standalone]

#28386

On 11/19/2012 04:52 AM, felix wrote:
> We were trying to understand which of those subroutines (ftell(3) or
> fflush(3)) would be more effective when used within the code. We
> wanted to make sure that we knew why we are using what we are using.

That's trivial: ftell() just retrieves data that's stored in the FILE
object (conceptually, at least - implementation details may differ) -
it's very quick. fflush() forces the buffers to be flushed earlier than
they otherwise would be. Assuming a reasonably competent implementation
of the standard I/O library (if you can't make that assumption, change
which library you're using), the flushing policy is presumably close to
optimum, and randomly interfering with that policy will cause a
significant reduction in I/O efficiency. You should interfere with the
buffering only when you have to - and in this case, you don't have to.
Also, ftell(), if executed after the immediately preceding write to the
file, will (on a binary stream, at least) returns exactly the quantity
that you're interested in. Calling fflush() improves the relevance of
the numbers you can get from stat(), but it's still not guaranteed to
give you the same number that ftell() would give you.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#28137

On 11/9/2012 2:09 AM, felix wrote:
> This method was written to create new Log File, when the size of the Log File reaches a max size defined by user [10MB in our case]. Here is the code snippet that does this check:
>
> //-- Code starts here : --
>
> static size_t LogSize = 1048576;

     Ah. This is obviously some strange usage of "10 MB" that
I hadn't previously been aware of.

> It is strange that the condition got satisfied when results.st_size = 2589116.

     Not all *that* strange ...

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#28166

On Nov 9, 1:24 pm, Eric Sosman <esos...@comcast-dot-net.invalid>
wrote:
> On 11/9/2012 2:09 AM, felix wrote:
>
> > This method was written to create new Log File, when the size of the Log File reaches a max size defined by user [10MB in our case]. Here is the code snippet that does this check:
>
> > //-- Code starts here : --
>
> > static size_t LogSize = 1048576;
>
>      Ah. This is obviously some strange usage of "10 MB" that
> I hadn't previously been aware of.
>
> > It is strange that the condition got satisfied when results.st_size = 2589116.
>
>      Not all *that* strange ...

this is why you don't put numbers like that in your code

#define K 1024
#define M (K * K)
#define LOG_SIZE (10 * M)

[toc] | [prev] | [next] | [standalone]

#28180

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:

> On Nov 9, 1:24 pm, Eric Sosman <esos...@comcast-dot-net.invalid>
> wrote:
>> On 11/9/2012 2:09 AM, felix wrote:
<snip>
>> > //-- Code starts here : --
>>
>> > static size_t LogSize = 1048576;
>>
>>      Ah. This is obviously some strange usage of "10 MB" that
>> I hadn't previously been aware of.
>>
>> > It is strange that the condition got satisfied when results.st_size
>> > = 2589116.
>>
>>      Not all *that* strange ...
>
> this is why you don't put numbers like that in your code
>
> #define K 1024
> #define M (K * K)
> #define LOG_SIZE (10 * M)

I'd put an 'L' suffix on the 1024 since 10 * M is outside the minimum
range or plain int arithmetic.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#28185

On 11/11/12 04:12, Ben Bacarisse wrote:
> Nick Keighley<nick_keighley_nospam@hotmail.com>  writes:
>
>> On Nov 9, 1:24 pm, Eric Sosman<esos...@comcast-dot-net.invalid>
>> wrote:
>>> On 11/9/2012 2:09 AM, felix wrote:
> <snip>
>>>> //-- Code starts here : --
>>>
>>>> static size_t LogSize = 1048576;
>>>
>>>       Ah. This is obviously some strange usage of "10 MB" that
>>> I hadn't previously been aware of.
>>>
>>>> It is strange that the condition got satisfied when results.st_size
>>>> = 2589116.
>>>
>>>       Not all *that* strange ...
>>
>> this is why you don't put numbers like that in your code
>>
>> #define K 1024
>> #define M (K * K)
>> #define LOG_SIZE (10 * M)
>
> I'd put an 'L' suffix on the 1024 since 10 * M is outside the minimum
> range or plain int arithmetic.

Or lust use

const size_t oneK    = 1024;
const size_t oneM    = oneK * 1024;
const size_t logSize = 10 * oneM;

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#28187

Ian Collins <ian-news@hotmail.com> writes:

> On 11/11/12 04:12, Ben Bacarisse wrote:
>> Nick Keighley<nick_keighley_nospam@hotmail.com>  writes:
>>
>>> On Nov 9, 1:24 pm, Eric Sosman<esos...@comcast-dot-net.invalid>
>>> wrote:
>>>> On 11/9/2012 2:09 AM, felix wrote:
>> <snip>
>>>>> //-- Code starts here : --
>>>>
>>>>> static size_t LogSize = 1048576;
>>>>
>>>>       Ah. This is obviously some strange usage of "10 MB" that
>>>> I hadn't previously been aware of.
>>>>
>>>>> It is strange that the condition got satisfied when results.st_size
>>>>> = 2589116.
>>>>
>>>>       Not all *that* strange ...
>>>
>>> this is why you don't put numbers like that in your code
>>>
>>> #define K 1024
>>> #define M (K * K)
>>> #define LOG_SIZE (10 * M)
>>
>> I'd put an 'L' suffix on the 1024 since 10 * M is outside the minimum
>> range or plain int arithmetic.
>
> Or lust use
>
> const size_t oneK    = 1024;
> const size_t oneM    = oneK * 1024;
> const size_t logSize = 10 * oneM;

Check the newsgroup!  That's more use in C++ than in C -- you can't put
these at file scope in C.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#28181

On 11/10/2012 9:06 AM, Nick Keighley wrote:
> On Nov 9, 1:24 pm, Eric Sosman <esos...@comcast-dot-net.invalid>
> wrote:
>> On 11/9/2012 2:09 AM, felix wrote:
>>
>>> This method was written to create new Log File, when the size of the Log File reaches a max size defined by user [10MB in our case]. Here is the code snippet that does this check:
>>
>>> //-- Code starts here : --
>>
>>> static size_t LogSize = 1048576;
>>
>>       Ah. This is obviously some strange usage of "10 MB" that
>> I hadn't previously been aware of.
>>
>>> It is strange that the condition got satisfied when results.st_size = 2589116.
>>
>>       Not all *that* strange ...
>
> this is why you don't put numbers like that in your code
>
> #define K 1024
> #define M (K * K)
> #define LOG_SIZE (10 * M)

     Ugh.  If you simply *must* do that sort of thing, at least
use identifiers like KILO and MEGA (or KIBI and MIBI).  Myself,
I'd prefer to write

	#define LOG_SIZE (10L * 1024 * 1024)

... with special emphasis on the "L".

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#28139

In <8439d649-fae9-4828-8a86-d0c7c8489aa5@googlegroups.com> felix <ckpradip@gmail.com> writes:

> static size_t LogSize = 1048576;

> 	if ( results.st_size > LogSize )

> It is strange that the condition got satisfied when
> results.st_size = 2589116.

You're surprised that 2589116 is greater than 1048576?

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#28140

On 09/11/2012 15:16, John Gordon wrote:
> In <8439d649-fae9-4828-8a86-d0c7c8489aa5@googlegroups.com> felix <ckpradip@gmail.com> writes:
>
>> static size_t LogSize = 1048576;
>
>> 	if ( results.st_size > LogSize )
>
>> It is strange that the condition got satisfied when
>> results.st_size = 2589116.
>
> You're surprised that 2589116 is greater than 1048576?

No. Given that "we are sure that the size of the data that is written is 
between 50 to 100 bytes in one operation. And this check is done before 
writing into the LogFile." I think the OP is surprised that the 
condition wasn't satisfied earlier.

I think James Kuyper has given some good advice.

[toc] | [prev] | [next] | [standalone]

#28141

On 11/09/2012 10:16 AM, John Gordon wrote:
> In <8439d649-fae9-4828-8a86-d0c7c8489aa5@googlegroups.com> felix <ckpradip@gmail.com> writes:
> 
>> static size_t LogSize = 1048576;
> 
>> 	if ( results.st_size > LogSize )
> 
>> It is strange that the condition got satisfied when
>> results.st_size = 2589116.
> 
> You're surprised that 2589116 is greater than 1048576?

No, he's surprised that, when checking this condition periodically,
separated by writes of no more than 100 bytes, that it doesn't trigger
until 2589116. Naively, it could be expected to trigger with
results.st_size no more than 100 bytes larger than LogSize. Buffering is
the simplest of the many reasons invalidating that conclusion; there's
several others, and many people who are better equipped to explain those
issues than I am, so I'll leave that explanation to them, rather than
embarrassing myself by getting it wrong.

[toc] | [prev] | [next] | [standalone]

#28142

On 12-11-08 11:09 PM, felix wrote:
> This method was written to create new Log File, when the size of the Log File reaches a max size defined by user [10MB in our case]. Here is the code snippet that does this check:
>
> //-- Code starts here : --
>
> static size_t LogSize = 1048576;
> bool CreateNewLogs = false;
>
>
> if ( stat ( logFile, &results ) == 0 )
> {
> 	if ( results.st_size > LogSize )
> 	{
> 		CreateNewLogs = true;
> 	}
> }
> //-- Code ends here   : --
>
> It is strange that the condition got satisfied when results.st_size = 2589116.
> And we are sure that the size of the data that is written is between 50 to 100 bytes in one operation. And this check is done before writing into the LogFile.
>
> I am not sure if I am missing anything in our understanding of the stat function. Any inputs or pointers on this regard will be really Helpful.
>
>
> Thanks in advance, and please let me know if any other information is required.
>
>
> --
> Felix
>

I would think it strange if I knew for sure that the function got called 
before the write in every place that the file was possibly being written 
to and that there weren't multiple process/threads that could write to it.

[toc] | [prev] | [next] | [standalone]

#28143

felix <ckpradip@gmail.com> writes:

> if ( stat ( logFile, &results ) == 0 )

Use ftell() instead (or lseek() at level 2).

-- Alain.

[toc] | [prev] | [next] | [standalone]

#28144

Alain Ketterlin <alain@dpt-info.u-strasbg.fr> writes:
> felix <ckpradip@gmail.com> writes:
>> if ( stat ( logFile, &results ) == 0 )
>
> Use ftell() instead (or lseek() at level 2).

What makes you think that will yield better results, and what is "level 2"?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#28146

Keith Thompson <kst-u@mib.org> writes:

> Alain Ketterlin <alain@dpt-info.u-strasbg.fr> writes:
>> felix <ckpradip@gmail.com> writes:
>>> if ( stat ( logFile, &results ) == 0 )
>>
>> Use ftell() instead (or lseek() at level 2).
>
> What makes you think that will yield better results,

What makes you think it will not. At least ftell() is C.

> and what is "level 2"?

Unixism. Just ignore it if it hurts you.

-- Alain.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web