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

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

position in file when saving

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

Contents

  position in file when saving fir <profesor.fir@gmail.com> - 2016-03-24 08:29 -0700
    Re: position in file when saving Barry Schwarz <schwarzb@dqel.com> - 2016-03-24 10:11 -0700
      Re: position in file when saving fir <profesor.fir@gmail.com> - 2016-03-24 10:51 -0700
        Re: position in file when saving Robert Wessel <robertwessel2@yahoo.com> - 2016-03-24 13:07 -0500
          Re: position in file when saving Stephen Sprunk <stephen@sprunk.org> - 2016-03-24 14:22 -0500
            Re: position in file when saving supercat@casperkitty.com - 2016-03-24 12:40 -0700
              Re: position in file when saving Keith Thompson <kst-u@mib.org> - 2016-03-24 12:57 -0700
                Re: position in file when saving supercat@casperkitty.com - 2016-03-24 13:15 -0700
                  Re: position in file when saving Keith Thompson <kst-u@mib.org> - 2016-03-24 15:06 -0700
                    Re: position in file when saving Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-24 20:29 -0400
                      Re: position in file when saving Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-25 01:42 +0000
                        Re: position in file when saving Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-24 23:07 -0400
                          Re: position in file when saving Ian Collins <ian-news@hotmail.com> - 2016-03-25 16:21 +1300
                            Re: position in file when saving Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-25 09:00 -0400
                          Re: position in file when saving Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-25 11:07 +0000
                            Re: position in file when saving Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-25 09:06 -0400
                              Re: position in file when saving Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-25 14:22 +0000
                                Re: position in file when saving Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-25 10:57 -0400
                                  Re: position in file when saving Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-25 16:31 +0000
                                    Re: position in file when saving Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-25 12:36 -0400
                                      Re: position in file when saving luser droog <luser.droog@gmail.com> - 2016-03-25 09:49 -0700
                                        Re: position in file when saving Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-25 13:00 -0400
                                      Re: position in file when saving Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-25 20:35 +0000
                                        Re: position in file when saving Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-25 16:59 -0400
                                    Re: position in file when saving Ian Collins <ian-news@hotmail.com> - 2016-03-26 10:46 +1300
                                      Re: position in file when saving Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-25 20:22 -0400
                                        Re: position in file when saving Ian Collins <ian-news@hotmail.com> - 2016-03-26 13:42 +1300
                                          Re: position in file when saving Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-26 09:17 -0400
                                        Re: position in file when saving supercat@casperkitty.com - 2016-03-26 07:50 -0700
                                          Re: position in file when saving Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-26 21:37 -0400
                                            Re: position in file when saving supercat@casperkitty.com - 2016-03-27 08:14 -0700
                                              Re: position in file when saving Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-27 12:45 -0400
                                                Re: position in file when saving supercat@casperkitty.com - 2016-03-27 12:20 -0700
                                                  Re: position in file when saving Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-27 17:07 -0400
                                                    Re: position in file when saving supercat@casperkitty.com - 2016-03-27 14:15 -0700
                                                      Re: position in file when saving Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-27 17:26 -0400
                                                      Re: position in file when saving Ken Brody <kenbrody@spamcop.net> - 2016-03-28 10:36 -0400
                                                        Re: position in file when saving Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-28 11:01 -0400
                                                          Re: position in file when saving David Brown <david.brown@hesbynett.no> - 2016-03-29 10:18 +0200
                                                            Re: position in file when saving Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-29 09:02 -0400
                                                              Re: position in file when saving Ian Collins <ian-news@hotmail.com> - 2016-03-30 08:24 +1300
                                                                Re: position in file when saving Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-29 15:57 -0400
                                                                  Re: position in file when saving Ian Collins <ian-news@hotmail.com> - 2016-03-30 09:04 +1300
                                                                    Re: position in file when saving Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-29 16:22 -0400
                                                                      Re: position in file when saving Ian Collins <ian-news@hotmail.com> - 2016-03-31 17:31 +1300
                                                                        Re: position in file when saving gazelle@shell.xmission.com (Kenny McCormack) - 2016-03-31 09:55 +0000
                                                                        Re: position in file when saving Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-31 10:01 -0400
                                                                    Re: position in file when saving Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-29 16:31 -0400
                                                                    Re: position in file when saving Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-30 17:27 -0400
                                                                      Re: position in file when saving Ian Collins <ian-news@hotmail.com> - 2016-03-31 16:19 +1300
                                                                        Re: position in file when saving Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-31 10:06 -0400
                                                Re: position in file when saving Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-29 05:21 -0700
                                                  Re: position in file when saving Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-29 09:05 -0400
                  Re: position in file when saving Ken Brody <kenbrody@spamcop.net> - 2016-03-25 14:33 -0400
                    Re: position in file when saving Keith Thompson <kst-u@mib.org> - 2016-03-25 11:38 -0700
                    Re: position in file when saving supercat@casperkitty.com - 2016-03-25 14:05 -0700
                    Re: position in file when saving Nick Bowler <nbowler@draconx.ca> - 2016-03-28 16:14 +0000
                      Re: position in file when saving Tim Rentsch <txr@alumni.caltech.edu> - 2016-03-30 09:31 -0700
            Re: position in file when saving Ian Collins <ian-news@hotmail.com> - 2016-03-25 15:06 +1300
          Re: position in file when saving Ian Collins <ian-news@hotmail.com> - 2016-03-25 15:00 +1300
    Re: position in file when saving Les Cargill <lcargill99@comcast.com> - 2016-03-24 22:15 -0500

Page 1 of 4  [1] 2 3 4  Next page →

#84816 — position in file when saving

I do a couple of fwrites (which save x bytes x is less than 512) Then i want to jump 512 byte in this written file to save another data

How i could do it good way? is there maybe a way of reading how many bytes was saved in opened file? or jump to 512 without counting?

[toc] | [next] | [standalone]

#84833

On Thu, 24 Mar 2016 08:29:16 -0700 (PDT), fir <profesor.fir@gmail.com>
wrote:

>I do a couple of fwrites (which save x bytes x is less than 512) Then i want to jump 512 byte in this written file to save another data
>
>How i could do it good way? is there maybe a way of reading how many bytes was saved in opened file? or jump to 512 without counting?

If you are creating the file and have written less than 512, there is
no position 512 to jump to.

fwrite returns the number of objects written.  You know the size of
each object for each call.  Keep a running total of the number of
bytes written so far.  Subtract from 512.  Write that many "spacer"
bytes and you are right where you want to be.

If you are appending to the file, it gets a bit more complicated.

-- 
Remove del for email

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

#84838

W dniu czwartek, 24 marca 2016 18:11:42 UTC+1 użytkownik Barry Schwarz napisał:
> On Thu, 24 Mar 2016 08:29:16 -0700 (PDT), fir <profesor.fir@gmail.com>
> wrote:
> 
> >I do a couple of fwrites (which save x bytes x is less than 512) Then i want to jump 512 byte in this written file to save another data
> >
> >How i could do it good way? is there maybe a way of reading how many bytes was saved in opened file? or jump to 512 without counting?
> 
> If you are creating the file and have written less than 512, there is
> no position 512 to jump to.
> 
> fwrite returns the number of objects written.  You know the size of
> each object for each call.  Keep a running total of the number of
> bytes written so far.  Subtract from 512.  Write that many "spacer"
> bytes and you are right where you want to be.
> 
> If you are appending to the file, it gets a bit more complicated.
> 
I checked and    fseek( file, 0x200, SEEK_SET ); works

it is good as it is much simpler than counting the bytes saved

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

#84840

On Thu, 24 Mar 2016 10:51:49 -0700 (PDT), fir <profesor.fir@gmail.com>
wrote:

>W dniu czwartek, 24 marca 2016 18:11:42 UTC+1 u?ytkownik Barry Schwarz napisa?:
>> On Thu, 24 Mar 2016 08:29:16 -0700 (PDT), fir <profesor.fir@gmail.com>
>> wrote:
>> 
>> >I do a couple of fwrites (which save x bytes x is less than 512) Then i want to jump 512 byte in this written file to save another data
>> >
>> >How i could do it good way? is there maybe a way of reading how many bytes was saved in opened file? or jump to 512 without counting?
>> 
>> If you are creating the file and have written less than 512, there is
>> no position 512 to jump to.
>> 
>> fwrite returns the number of objects written.  You know the size of
>> each object for each call.  Keep a running total of the number of
>> bytes written so far.  Subtract from 512.  Write that many "spacer"
>> bytes and you are right where you want to be.
>> 
>> If you are appending to the file, it gets a bit more complicated.
>> 
>I checked and    fseek( file, 0x200, SEEK_SET ); works
>
>it is good as it is much simpler than counting the bytes saved


I don't believe there's any defined behavior according to the standard
for seeking past the end of a file and then writing.  On some
platforms it will pad the file with zeros to the point of the write.
On some system that also triggers the creation of a sparse file.

But it's not something you can generally rely on.

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

#84852

On 24-Mar-16 13:07, Robert Wessel wrote:
> fir <profesor.fir@gmail.com> wrote:
>> I checked and    fseek( file, 0x200, SEEK_SET ); works
>>
>> it is good as it is much simpler than counting the bytes saved
> 
> I don't believe there's any defined behavior according to the
> standard for seeking past the end of a file and then writing.  On
> some platforms it will pad the file with zeros to the point of the
> write. On some system that also triggers the creation of a sparse
> file.
> 
> But it's not something you can generally rely on.

It's actually worse than that; fseek()'s behavior is only defined when
passed the result of a previous call to ftell().  An implementation
_could_ have ftell() put the actual file position (e.g. record number
and offset) in a table and just return the index and fseek() look up
that index in the table to find the actual file position.  Byte offsets
would likely be invalid indexes or, worse, valid indexes for unrelated
file positions.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#84854

On Thursday, March 24, 2016 at 2:22:35 PM UTC-5, Stephen Sprunk wrote:
> It's actually worse than that; fseek()'s behavior is only defined when
> passed the result of a previous call to ftell().  An implementation
> _could_ have ftell() put the actual file position (e.g. record number
> and offset) in a table and just return the index and fseek() look up
> that index in the table to find the actual file position.  Byte offsets
> would likely be invalid indexes or, worse, valid indexes for unrelated
> file positions.

Is there any requirement that the previous call to ftell() must have been
performed within the current execution of the program?  Also, by what means
if any could a current-position-relative fseek() ever have meaningfully-
defined behavior?

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

#84856

supercat@casperkitty.com writes:
> On Thursday, March 24, 2016 at 2:22:35 PM UTC-5, Stephen Sprunk wrote:
>> It's actually worse than that; fseek()'s behavior is only defined when
>> passed the result of a previous call to ftell().  An implementation
>> _could_ have ftell() put the actual file position (e.g. record number
>> and offset) in a table and just return the index and fseek() look up
>> that index in the table to find the actual file position.  Byte offsets
>> would likely be invalid indexes or, worse, valid indexes for unrelated
>> file positions.
>
> Is there any requirement that the previous call to ftell() must have been
> performed within the current execution of the program?  Also, by what means
> if any could a current-position-relative fseek() ever have meaningfully-
> defined behavior?

Have you checked N1570 7.21.9.2?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"

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

#84859

On Thursday, March 24, 2016 at 2:57:28 PM UTC-5, Keith Thompson wrote:
> supercat writes:
> > Is there any requirement that the previous call to ftell() must have been
> > performed within the current execution of the program?  Also, by what means
> > if any could a current-position-relative fseek() ever have meaningfully-
> > defined behavior?
> 
> Have you checked N1570 7.21.9.2?

I should have omitted the follow-on question, but I think the first is
valid and the cited section doesn't mention it.  The possibility that the
call may have been made on a previous execution of the program isn't
merely a theoretical exercise.  Some implementations of "fortune" have
an index file that contains the offset to the start of each entry in the
main text file; is such an approach guaranteed to work?

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

#84867

supercat@casperkitty.com writes:
> On Thursday, March 24, 2016 at 2:57:28 PM UTC-5, Keith Thompson wrote:
>> supercat writes:
>> > Is there any requirement that the previous call to ftell() must
>> > have been performed within the current execution of the program?
>> > Also, by what means if any could a current-position-relative
>> > fseek() ever have meaningfully- defined behavior?
>> 
>> Have you checked N1570 7.21.9.2?
>
> I should have omitted the follow-on question, but I think the first is
> valid and the cited section doesn't mention it.  The possibility that the
> call may have been made on a previous execution of the program isn't
> merely a theoretical exercise.  Some implementations of "fortune" have
> an index file that contains the offset to the start of each entry in the
> main text file; is such an approach guaranteed to work?

It says "a value returned by an earlier successful call to the ftell
function on a stream associated with the same file".  If it said "the
same stream", I'd say it has to be within the current execution, but a
*file* can persist across multiple executions, or even executions of
different programs.  (That's pretty much what files are for, after all.)

My interpretation is that it can use a saved position from a previous
execution.  (Unless of course the file has changed, but the committee
left that can of worms closed, or at least indeterminate.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"

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

#84873

On 3/24/2016 6:06 PM, Keith Thompson wrote:
> supercat@casperkitty.com writes:
>> On Thursday, March 24, 2016 at 2:57:28 PM UTC-5, Keith Thompson wrote:
>>> supercat writes:
>>>> Is there any requirement that the previous call to ftell() must
>>>> have been performed within the current execution of the program?
>>>> Also, by what means if any could a current-position-relative
>>>> fseek() ever have meaningfully- defined behavior?
>>>
>>> Have you checked N1570 7.21.9.2?
>>
>> I should have omitted the follow-on question, but I think the first is
>> valid and the cited section doesn't mention it.  The possibility that the
>> call may have been made on a previous execution of the program isn't
>> merely a theoretical exercise.  Some implementations of "fortune" have
>> an index file that contains the offset to the start of each entry in the
>> main text file; is such an approach guaranteed to work?
> 
> It says "a value returned by an earlier successful call to the ftell
> function on a stream associated with the same file".  If it said "the
> same stream", I'd say it has to be within the current execution, but a
> *file* can persist across multiple executions, or even executions of
> different programs.  (That's pretty much what files are for, after all.)
> 
> My interpretation is that it can use a saved position from a previous
> execution.  (Unless of course the file has changed, but the committee
> left that can of worms closed, or at least indeterminate.)
> 

When the program ends, all streams are closed.  There is no previous
stream to be associated with the same file.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#84878

Jerry Stuckle <jstucklex@attglobal.net> writes:

> On 3/24/2016 6:06 PM, Keith Thompson wrote:
>> supercat@casperkitty.com writes:
>>> On Thursday, March 24, 2016 at 2:57:28 PM UTC-5, Keith Thompson wrote:
>>>> supercat writes:
>>>>> Is there any requirement that the previous call to ftell() must
>>>>> have been performed within the current execution of the program?
>>>>> Also, by what means if any could a current-position-relative
>>>>> fseek() ever have meaningfully- defined behavior?
>>>>
>>>> Have you checked N1570 7.21.9.2?
>>>
>>> I should have omitted the follow-on question, but I think the first is
>>> valid and the cited section doesn't mention it.  The possibility that the
>>> call may have been made on a previous execution of the program isn't
>>> merely a theoretical exercise.  Some implementations of "fortune" have
>>> an index file that contains the offset to the start of each entry in the
>>> main text file; is such an approach guaranteed to work?
>> 
>> It says "a value returned by an earlier successful call to the ftell
>> function on a stream associated with the same file".  If it said "the
>> same stream", I'd say it has to be within the current execution, but a
>> *file* can persist across multiple executions, or even executions of
>> different programs.  (That's pretty much what files are for, after all.)
>> 
>> My interpretation is that it can use a saved position from a previous
>> execution.  (Unless of course the file has changed, but the committee
>> left that can of worms closed, or at least indeterminate.) 
>
> When the program ends, all streams are closed.

That's not universally true.  Open files are not guaranteed to be closed
when the program ends (see, for example, the abort function).

> There is no previous
> stream to be associated with the same file.

But the text refers to a previous "value returned by an earlier
successful call to the ftell function on a stream associated with the
same file".  All that is needed is that there be a stream (a new one as
you say) associated with the old file.  It doesn't matter that the
stream once used to get the ftell value is no longer around.

-- 
Ben.

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

#84882

On 3/24/2016 9:42 PM, Ben Bacarisse wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
> 
>> On 3/24/2016 6:06 PM, Keith Thompson wrote:
>>> supercat@casperkitty.com writes:
>>>> On Thursday, March 24, 2016 at 2:57:28 PM UTC-5, Keith Thompson wrote:
>>>>> supercat writes:
>>>>>> Is there any requirement that the previous call to ftell() must
>>>>>> have been performed within the current execution of the program?
>>>>>> Also, by what means if any could a current-position-relative
>>>>>> fseek() ever have meaningfully- defined behavior?
>>>>>
>>>>> Have you checked N1570 7.21.9.2?
>>>>
>>>> I should have omitted the follow-on question, but I think the first is
>>>> valid and the cited section doesn't mention it.  The possibility that the
>>>> call may have been made on a previous execution of the program isn't
>>>> merely a theoretical exercise.  Some implementations of "fortune" have
>>>> an index file that contains the offset to the start of each entry in the
>>>> main text file; is such an approach guaranteed to work?
>>>
>>> It says "a value returned by an earlier successful call to the ftell
>>> function on a stream associated with the same file".  If it said "the
>>> same stream", I'd say it has to be within the current execution, but a
>>> *file* can persist across multiple executions, or even executions of
>>> different programs.  (That's pretty much what files are for, after all.)
>>>
>>> My interpretation is that it can use a saved position from a previous
>>> execution.  (Unless of course the file has changed, but the committee
>>> left that can of worms closed, or at least indeterminate.) 
>>
>> When the program ends, all streams are closed.
> 
> That's not universally true.  Open files are not guaranteed to be closed
> when the program ends (see, for example, the abort function).
> 

And when abort is called, the OS is responsible for cleaning up
resources - including streams and memory.  Otherwise they would just
build until they take all of the system resources or until the system is
restarted.  And I don't know about you, but I've had servers running for
over 2 years with no reboots and no shortage of resources.

>> There is no previous
>> stream to be associated with the same file.
> 
> But the text refers to a previous "value returned by an earlier
> successful call to the ftell function on a stream associated with the
> same file".  All that is needed is that there be a stream (a new one as
> you say) associated with the old file.  It doesn't matter that the
> stream once used to get the ftell value is no longer around.
> 

A new stream starts at the beginning or end of the file, depending on
how it was opened (read/write/append).  And if the stream is no longer
around, neither is any residual information on the location of the
stream when it was closed.  That's all freed up also.

Plus, OS's don't keep track of which executable is accessing the file.
They just go by the procid.  Sure, they *could* get the program name
through the proc id, but why?  Once the progam starts, the system
doesn't know or care until the program ends, especially if its an
abnormal end.

What does work is to open the file in this procid and not close it.  Now
you can use ftell() to find your location no matter how long it has been
open.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#84885

On 03/25/16 16:07, Jerry Stuckle wrote:
>
> And when abort is called, the OS is responsible for cleaning up
> resources - including streams and memory.  Otherwise they would just
> build until they take all of the system resources or until the system is
> restarted.  And I don't know about you, but I've had servers running for
> over 2 years with no reboots and no shortage of resources.

...and no shortage of security vulnerabilities :)

Mind you, we did recently reboot an old inside the firewall SPARC box 
with over 1600 days of uptime.  That's how we knew how many days had 
passed since our last decent earthquake..

-- 
Ian Collins

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

#84914

On 3/24/2016 11:21 PM, Ian Collins wrote:
> On 03/25/16 16:07, Jerry Stuckle wrote:
>>
>> And when abort is called, the OS is responsible for cleaning up
>> resources - including streams and memory.  Otherwise they would just
>> build until they take all of the system resources or until the system is
>> restarted.  And I don't know about you, but I've had servers running for
>> over 2 years with no reboots and no shortage of resources.
> 
> ...and no shortage of security vulnerabilities :)
> 
> Mind you, we did recently reboot an old inside the firewall SPARC box
> with over 1600 days of uptime.  That's how we knew how many days had
> passed since our last decent earthquake..
> 

This isn't Windows.  You don't always need to reboot when updating.
Simply restarting the affected services is enough.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#84898

Jerry Stuckle <jstucklex@attglobal.net> writes:

> On 3/24/2016 9:42 PM, Ben Bacarisse wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>> 
>>> On 3/24/2016 6:06 PM, Keith Thompson wrote:
>>>> supercat@casperkitty.com writes:
>>>>> On Thursday, March 24, 2016 at 2:57:28 PM UTC-5, Keith Thompson wrote:
>>>>>> supercat writes:
>>>>>>> Is there any requirement that the previous call to ftell() must
>>>>>>> have been performed within the current execution of the program?
>>>>>>> Also, by what means if any could a current-position-relative
>>>>>>> fseek() ever have meaningfully- defined behavior?
>>>>>>
>>>>>> Have you checked N1570 7.21.9.2?
>>>>>
>>>>> I should have omitted the follow-on question, but I think the first is
>>>>> valid and the cited section doesn't mention it.  The possibility that the
>>>>> call may have been made on a previous execution of the program isn't
>>>>> merely a theoretical exercise.  Some implementations of "fortune" have
>>>>> an index file that contains the offset to the start of each entry in the
>>>>> main text file; is such an approach guaranteed to work?
>>>>
>>>> It says "a value returned by an earlier successful call to the ftell
>>>> function on a stream associated with the same file".  If it said "the
>>>> same stream", I'd say it has to be within the current execution, but a
>>>> *file* can persist across multiple executions, or even executions of
>>>> different programs.  (That's pretty much what files are for, after all.)
>>>>
>>>> My interpretation is that it can use a saved position from a previous
>>>> execution.  (Unless of course the file has changed, but the committee
>>>> left that can of worms closed, or at least indeterminate.) 
>>>
>>> When the program ends, all streams are closed.
>> 
>> That's not universally true.  Open files are not guaranteed to be closed
>> when the program ends (see, for example, the abort function).
>> 
>
> And when abort is called, the OS is responsible for cleaning up
> resources - including streams and memory.

You are mixing up two things -- closing the file and cleaning up
resources.  For example, in C, closing an output file flushes any
pending output.  C gives an implementation permission to "not close all
files" on abort because it does not want to force all implementations to
have to do that flushing in all cases.

It also helps to be clear about what usually happens and what must
happen according to the language standard.  An implementation is
permitted to close all open files (in the C sense, that is) on abort --
it's just not obliged to.

<snip>
>>> There is no previous
>>> stream to be associated with the same file.
>> 
>> But the text refers to a previous "value returned by an earlier
>> successful call to the ftell function on a stream associated with the
>> same file".  All that is needed is that there be a stream (a new one as
>> you say) associated with the old file.  It doesn't matter that the
>> stream once used to get the ftell value is no longer around.
>> 
>
> A new stream starts at the beginning or end of the file, depending on
> how it was opened (read/write/append).  And if the stream is no longer
> around, neither is any residual information on the location of the
> stream when it was closed.  That's all freed up also.

I think you've just lost track of what the question was.  It is this: if
a program fseeks an open file and records the value returned by ftell in
some permanent way (maybe in some other file), can a second program open
that file, read the saved value and use it in a fseek call?

<snip>
-- 
Ben.

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

#84916

On 3/25/2016 7:07 AM, Ben Bacarisse wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
> 
>> On 3/24/2016 9:42 PM, Ben Bacarisse wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>
>>>> On 3/24/2016 6:06 PM, Keith Thompson wrote:
>>>>> supercat@casperkitty.com writes:
>>>>>> On Thursday, March 24, 2016 at 2:57:28 PM UTC-5, Keith Thompson wrote:
>>>>>>> supercat writes:
>>>>>>>> Is there any requirement that the previous call to ftell() must
>>>>>>>> have been performed within the current execution of the program?
>>>>>>>> Also, by what means if any could a current-position-relative
>>>>>>>> fseek() ever have meaningfully- defined behavior?
>>>>>>>
>>>>>>> Have you checked N1570 7.21.9.2?
>>>>>>
>>>>>> I should have omitted the follow-on question, but I think the first is
>>>>>> valid and the cited section doesn't mention it.  The possibility that the
>>>>>> call may have been made on a previous execution of the program isn't
>>>>>> merely a theoretical exercise.  Some implementations of "fortune" have
>>>>>> an index file that contains the offset to the start of each entry in the
>>>>>> main text file; is such an approach guaranteed to work?
>>>>>
>>>>> It says "a value returned by an earlier successful call to the ftell
>>>>> function on a stream associated with the same file".  If it said "the
>>>>> same stream", I'd say it has to be within the current execution, but a
>>>>> *file* can persist across multiple executions, or even executions of
>>>>> different programs.  (That's pretty much what files are for, after all.)
>>>>>
>>>>> My interpretation is that it can use a saved position from a previous
>>>>> execution.  (Unless of course the file has changed, but the committee
>>>>> left that can of worms closed, or at least indeterminate.) 
>>>>
>>>> When the program ends, all streams are closed.
>>>
>>> That's not universally true.  Open files are not guaranteed to be closed
>>> when the program ends (see, for example, the abort function).
>>>
>>
>> And when abort is called, the OS is responsible for cleaning up
>> resources - including streams and memory.
> 
> You are mixing up two things -- closing the file and cleaning up
> resources.  For example, in C, closing an output file flushes any
> pending output.  C gives an implementation permission to "not close all
> files" on abort because it does not want to force all implementations to
> have to do that flushing in all cases.
>

No, I'm not.  You're the confused one.  There are typically two sets or
buffers - in C and in the OS.  When the file is closed, the C buffer is
flushed as well as the OS buffer.  But if there is an abort, the C
buffer does not get flushed and any data in it is still lost.

C cannot "give an implementation permission...".  The implementation
decides what it will do.  And every OS out there closes the files and
releases all information related to the stream when the program
terminates, normally or abnormally.

> It also helps to be clear about what usually happens and what must
> happen according to the language standard.  An implementation is
> permitted to close all open files (in the C sense, that is) on abort --
> it's just not obliged to.
> 

What the OS does has absolutely nothing to do with a language standard.

> <snip>
>>>> There is no previous
>>>> stream to be associated with the same file.
>>>
>>> But the text refers to a previous "value returned by an earlier
>>> successful call to the ftell function on a stream associated with the
>>> same file".  All that is needed is that there be a stream (a new one as
>>> you say) associated with the old file.  It doesn't matter that the
>>> stream once used to get the ftell value is no longer around.
>>>
>>
>> A new stream starts at the beginning or end of the file, depending on
>> how it was opened (read/write/append).  And if the stream is no longer
>> around, neither is any residual information on the location of the
>> stream when it was closed.  That's all freed up also.
> 
> I think you've just lost track of what the question was.  It is this: if
> a program fseeks an open file and records the value returned by ftell in
> some permanent way (maybe in some other file), can a second program open
> that file, read the saved value and use it in a fseek call?
> 
> <snip>
> 

Nope, I lost track of nothing.  When the second program opens the file,
it will get a new stream, which will point at the beginning or end of
the file, depending on the open mode (i.e. read or write vs. append).

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#84928

Jerry Stuckle <jstucklex@attglobal.net> writes:

> On 3/25/2016 7:07 AM, Ben Bacarisse wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>> 
>>> On 3/24/2016 9:42 PM, Ben Bacarisse wrote:
>>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>>
>>>>> On 3/24/2016 6:06 PM, Keith Thompson wrote:
>>>>>> supercat@casperkitty.com writes:
>>>>>>> On Thursday, March 24, 2016 at 2:57:28 PM UTC-5, Keith Thompson wrote:
>>>>>>>> supercat writes:
>>>>>>>>> Is there any requirement that the previous call to ftell() must
>>>>>>>>> have been performed within the current execution of the program?
>>>>>>>>> Also, by what means if any could a current-position-relative
>>>>>>>>> fseek() ever have meaningfully- defined behavior?
>>>>>>>>
>>>>>>>> Have you checked N1570 7.21.9.2?
>>>>>>>
>>>>>>> I should have omitted the follow-on question, but I think the first is
>>>>>>> valid and the cited section doesn't mention it.  The possibility that the
>>>>>>> call may have been made on a previous execution of the program isn't
>>>>>>> merely a theoretical exercise.  Some implementations of "fortune" have
>>>>>>> an index file that contains the offset to the start of each entry in the
>>>>>>> main text file; is such an approach guaranteed to work?
>>>>>>
>>>>>> It says "a value returned by an earlier successful call to the ftell
>>>>>> function on a stream associated with the same file".  If it said "the
>>>>>> same stream", I'd say it has to be within the current execution, but a
>>>>>> *file* can persist across multiple executions, or even executions of
>>>>>> different programs.  (That's pretty much what files are for, after all.)
>>>>>>
>>>>>> My interpretation is that it can use a saved position from a previous
>>>>>> execution.  (Unless of course the file has changed, but the committee
>>>>>> left that can of worms closed, or at least indeterminate.) 
>>>>>
>>>>> When the program ends, all streams are closed.
>>>>
>>>> That's not universally true.  Open files are not guaranteed to be closed
>>>> when the program ends (see, for example, the abort function).
>>>>
>>>
>>> And when abort is called, the OS is responsible for cleaning up
>>> resources - including streams and memory.
>> 
>> You are mixing up two things -- closing the file and cleaning up
>> resources.  For example, in C, closing an output file flushes any
>> pending output.  C gives an implementation permission to "not close all
>> files" on abort because it does not want to force all implementations to
>> have to do that flushing in all cases.
>
> No, I'm not.  You're the confused one.  There are typically two sets or
> buffers - in C and in the OS.  When the file is closed, the C buffer is
> flushed as well as the OS buffer.  But if there is an abort, the C
> buffer does not get flushed and any data in it is still lost.

It's odd.  You often come round to agreeing with me but you prefix that
agreement with "no" as if to keep the agreement going.

The final thing you have to come round to agreeing with is that for C
(and this is comp.lang.c) closing an open file means flushing the
buffers which is why the C standard does not insist that an
implementation closes all open files on abort.

> C cannot "give an implementation permission...".  The implementation
> decides what it will do.  And every OS out there closes the files and
> releases all information related to the stream when the program
> terminates, normally or abnormally.

I'm sorry of you don't like the term.  You don't disagree with the
facts: an implementation can be conforming even if it does not flush
output buffers on about.  The C standard permits this by saying that
open files do not have to be closed on abort.  If it said otherwise, the
implementations you describe would be non-conforming.

>> It also helps to be clear about what usually happens and what must
>> happen according to the language standard.  An implementation is
>> permitted to close all open files (in the C sense, that is) on abort --
>> it's just not obliged to.
>> 
>
> What the OS does has absolutely nothing to do with a language
> standard.

Quite.  But if what the OS does makes meeting the requirements of the
language impossible, you would not be able to implement a conforming C
system on that OS.  Fortunately, the C standard permits exactly the
behaviour you describe.

>> <snip>
>>>>> There is no previous
>>>>> stream to be associated with the same file.
>>>>
>>>> But the text refers to a previous "value returned by an earlier
>>>> successful call to the ftell function on a stream associated with the
>>>> same file".  All that is needed is that there be a stream (a new one as
>>>> you say) associated with the old file.  It doesn't matter that the
>>>> stream once used to get the ftell value is no longer around.
>>>>
>>>
>>> A new stream starts at the beginning or end of the file, depending on
>>> how it was opened (read/write/append).  And if the stream is no longer
>>> around, neither is any residual information on the location of the
>>> stream when it was closed.  That's all freed up also.
>> 
>> I think you've just lost track of what the question was.  It is this: if
>> a program fseeks an open file and records the value returned by ftell in
>> some permanent way (maybe in some other file), can a second program open
>> that file, read the saved value and use it in a fseek call?
>> 
>> <snip>
>> 
>
> Nope, I lost track of nothing.  When the second program opens the file,
> it will get a new stream, which will point at the beginning or end of
> the file, depending on the open mode (i.e. read or write vs. append).

A fact no one disputes.  The question was about using the value of ftell
from a previous execution of the program.  I suspect that you don't
dispute the facts about *that* question either.

-- 
Ben.

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

#84936

On 3/25/2016 10:22 AM, Ben Bacarisse wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
> 
>> On 3/25/2016 7:07 AM, Ben Bacarisse wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>
>>>> On 3/24/2016 9:42 PM, Ben Bacarisse wrote:
>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>>>
>>>>>> On 3/24/2016 6:06 PM, Keith Thompson wrote:
>>>>>>> supercat@casperkitty.com writes:
>>>>>>>> On Thursday, March 24, 2016 at 2:57:28 PM UTC-5, Keith Thompson wrote:
>>>>>>>>> supercat writes:
>>>>>>>>>> Is there any requirement that the previous call to ftell() must
>>>>>>>>>> have been performed within the current execution of the program?
>>>>>>>>>> Also, by what means if any could a current-position-relative
>>>>>>>>>> fseek() ever have meaningfully- defined behavior?
>>>>>>>>>
>>>>>>>>> Have you checked N1570 7.21.9.2?
>>>>>>>>
>>>>>>>> I should have omitted the follow-on question, but I think the first is
>>>>>>>> valid and the cited section doesn't mention it.  The possibility that the
>>>>>>>> call may have been made on a previous execution of the program isn't
>>>>>>>> merely a theoretical exercise.  Some implementations of "fortune" have
>>>>>>>> an index file that contains the offset to the start of each entry in the
>>>>>>>> main text file; is such an approach guaranteed to work?
>>>>>>>
>>>>>>> It says "a value returned by an earlier successful call to the ftell
>>>>>>> function on a stream associated with the same file".  If it said "the
>>>>>>> same stream", I'd say it has to be within the current execution, but a
>>>>>>> *file* can persist across multiple executions, or even executions of
>>>>>>> different programs.  (That's pretty much what files are for, after all.)
>>>>>>>
>>>>>>> My interpretation is that it can use a saved position from a previous
>>>>>>> execution.  (Unless of course the file has changed, but the committee
>>>>>>> left that can of worms closed, or at least indeterminate.) 
>>>>>>
>>>>>> When the program ends, all streams are closed.
>>>>>
>>>>> That's not universally true.  Open files are not guaranteed to be closed
>>>>> when the program ends (see, for example, the abort function).
>>>>>
>>>>
>>>> And when abort is called, the OS is responsible for cleaning up
>>>> resources - including streams and memory.
>>>
>>> You are mixing up two things -- closing the file and cleaning up
>>> resources.  For example, in C, closing an output file flushes any
>>> pending output.  C gives an implementation permission to "not close all
>>> files" on abort because it does not want to force all implementations to
>>> have to do that flushing in all cases.
>>
>> No, I'm not.  You're the confused one.  There are typically two sets or
>> buffers - in C and in the OS.  When the file is closed, the C buffer is
>> flushed as well as the OS buffer.  But if there is an abort, the C
>> buffer does not get flushed and any data in it is still lost.
> 
> It's odd.  You often come round to agreeing with me but you prefix that
> agreement with "no" as if to keep the agreement going.
> 
> The final thing you have to come round to agreeing with is that for C
> (and this is comp.lang.c) closing an open file means flushing the
> buffers which is why the C standard does not insist that an
> implementation closes all open files on abort.
>

We are not in agreement.  When a C program terminates, all data
associated with all streams associated with that program is deleted.  If
the C library closes the file (directly or indirectly), the C buffers
are written to the OS.  If the program terminates abnormally, those
buffers are not written to the OS and data is lost.

Once the program terminates, the OS closes any remaining open streams,
scheduling the buffers to be written to disk.  And data in these buffers
is not lost, although they may be written at some later time.

But in any case, when the streams are closed - either by C or the OS,
ALL data structures associated with the file are released.  There is
nothing for a later run of the program to use in ftell().

>> C cannot "give an implementation permission...".  The implementation
>> decides what it will do.  And every OS out there closes the files and
>> releases all information related to the stream when the program
>> terminates, normally or abnormally.
> 
> I'm sorry of you don't like the term.  You don't disagree with the
> facts: an implementation can be conforming even if it does not flush
> output buffers on about.  The C standard permits this by saying that
> open files do not have to be closed on abort.  If it said otherwise, the
> implementations you describe would be non-conforming.
> 

No, because the OS does the closing - even in the case of a serious
error like a segfault.  This has nothing to do with the C standard.  It
applies to ALL languages.

>>> It also helps to be clear about what usually happens and what must
>>> happen according to the language standard.  An implementation is
>>> permitted to close all open files (in the C sense, that is) on abort --
>>> it's just not obliged to.
>>>
>>
>> What the OS does has absolutely nothing to do with a language
>> standard.
> 
> Quite.  But if what the OS does makes meeting the requirements of the
> language impossible, you would not be able to implement a conforming C
> system on that OS.  Fortunately, the C standard permits exactly the
> behaviour you describe.
> 

I'm not into "what if's".  Name one OS which does this.

>>> <snip>
>>>>>> There is no previous
>>>>>> stream to be associated with the same file.
>>>>>
>>>>> But the text refers to a previous "value returned by an earlier
>>>>> successful call to the ftell function on a stream associated with the
>>>>> same file".  All that is needed is that there be a stream (a new one as
>>>>> you say) associated with the old file.  It doesn't matter that the
>>>>> stream once used to get the ftell value is no longer around.
>>>>>
>>>>
>>>> A new stream starts at the beginning or end of the file, depending on
>>>> how it was opened (read/write/append).  And if the stream is no longer
>>>> around, neither is any residual information on the location of the
>>>> stream when it was closed.  That's all freed up also.
>>>
>>> I think you've just lost track of what the question was.  It is this: if
>>> a program fseeks an open file and records the value returned by ftell in
>>> some permanent way (maybe in some other file), can a second program open
>>> that file, read the saved value and use it in a fseek call?
>>>
>>> <snip>
>>>
>>
>> Nope, I lost track of nothing.  When the second program opens the file,
>> it will get a new stream, which will point at the beginning or end of
>> the file, depending on the open mode (i.e. read or write vs. append).
> 
> A fact no one disputes.  The question was about using the value of ftell
> from a previous execution of the program.  I suspect that you don't
> dispute the facts about *that* question either.
> 

That's what you don't get.  There is no ftell() from a previous
execution of the program.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#84945

Jerry Stuckle <jstucklex@attglobal.net> writes:

> On 3/25/2016 10:22 AM, Ben Bacarisse wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>> 
>>> On 3/25/2016 7:07 AM, Ben Bacarisse wrote:
<snip>
>>>>>>>>>> supercat writes:
>>>>>>>>>>> Is there any requirement that the previous call to ftell() must
>>>>>>>>>>> have been performed within the current execution of the program?

This was the question that you've got all confused about.

I've cut your generalisations about what you think all OSs do because
they just cloud the issue.

<snip>
>>>> I think you've just lost track of what the question was.  It is this: if
>>>> a program fseeks an open file and records the value returned by ftell in
>>>> some permanent way (maybe in some other file), can a second program open
>>>> that file, read the saved value and use it in a fseek call?
>>>>
>>>> <snip>
>>>>
>>>
>>> Nope, I lost track of nothing.  When the second program opens the file,
>>> it will get a new stream, which will point at the beginning or end of
>>> the file, depending on the open mode (i.e. read or write vs. append).
>> 
>> A fact no one disputes.  The question was about using the value of ftell
>> from a previous execution of the program.  I suspect that you don't
>> dispute the facts about *that* question either.
>
> That's what you don't get.  There is no ftell() from a previous
> execution of the program.

There is result from a previous execution of the program.  Here it is as
concrete C code.  The question is whether this program has well-defined
behaviour.

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv)
{
     if (argc != 3) {
          fprintf(stderr, "I need two file names: "
                  "a file to seek and one to save the result of ftell.\n");
          return EXIT_FAILURE;
     }
     FILE *read_me = fopen(argv[1], "rb");
     if (!read_me) {
          fprintf(stderr, "%s was not readable.\n", argv[1]);
          return EXIT_FAILURE;
     }
     FILE *saved_ftell = fopen(argv[2], "r");
     long pos;
     if (saved_ftell && fscanf(saved_ftell, "%ld", &pos) == 1) {
          if (fseek(read_me, pos, SEEK_SET) != 0) {
               fprintf(stderr, "Seek to position %ld on %s failed.\n",
                       pos, argv[1]);
               return EXIT_FAILURE;
          }
          printf("Success.\nSeeked %s to position %ld read from %s.\n",
                 argv[1], pos, argv[2]);
     }
     else {
          FILE *save_ftell = fopen(argv[2], "w");
          if (!save_ftell ||
              fseek(read_me, 5, SEEK_SET) != 0 ||
              fprintf(save_ftell, "%ld\n", ftell(read_me)) != 2) {
               fprintf(stderr, "Something went wrong!\n");
               return EXIT_FAILURE;
          }
          printf("Seeked %s and saved the position in %s.\n", argv[1], argv[2]);
     }
     return EXIT_SUCCESS;
}

-- 
Ben.

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

#84946

On 3/25/2016 12:31 PM, Ben Bacarisse wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
> 
>> On 3/25/2016 10:22 AM, Ben Bacarisse wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>
>>>> On 3/25/2016 7:07 AM, Ben Bacarisse wrote:
> <snip>
>>>>>>>>>>> supercat writes:
>>>>>>>>>>>> Is there any requirement that the previous call to ftell() must
>>>>>>>>>>>> have been performed within the current execution of the program?
> 
> This was the question that you've got all confused about.
> 
> I've cut your generalisations about what you think all OSs do because
> they just cloud the issue.
>

There is no confusion at all about it.

> <snip>
>>>>> I think you've just lost track of what the question was.  It is this: if
>>>>> a program fseeks an open file and records the value returned by ftell in
>>>>> some permanent way (maybe in some other file), can a second program open
>>>>> that file, read the saved value and use it in a fseek call?
>>>>>
>>>>> <snip>
>>>>>
>>>>
>>>> Nope, I lost track of nothing.  When the second program opens the file,
>>>> it will get a new stream, which will point at the beginning or end of
>>>> the file, depending on the open mode (i.e. read or write vs. append).
>>>
>>> A fact no one disputes.  The question was about using the value of ftell
>>> from a previous execution of the program.  I suspect that you don't
>>> dispute the facts about *that* question either.
>>
>> That's what you don't get.  There is no ftell() from a previous
>> execution of the program.
> 
> There is result from a previous execution of the program.  Here it is as
> concrete C code.  The question is whether this program has well-defined
> behaviour.
> 
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main(int argc, char **argv)
> {
>      if (argc != 3) {
>           fprintf(stderr, "I need two file names: "
>                   "a file to seek and one to save the result of ftell.\n");
>           return EXIT_FAILURE;
>      }
>      FILE *read_me = fopen(argv[1], "rb");
>      if (!read_me) {
>           fprintf(stderr, "%s was not readable.\n", argv[1]);
>           return EXIT_FAILURE;
>      }
>      FILE *saved_ftell = fopen(argv[2], "r");
>      long pos;
>      if (saved_ftell && fscanf(saved_ftell, "%ld", &pos) == 1) {
>           if (fseek(read_me, pos, SEEK_SET) != 0) {
>                fprintf(stderr, "Seek to position %ld on %s failed.\n",
>                        pos, argv[1]);
>                return EXIT_FAILURE;
>           }
>           printf("Success.\nSeeked %s to position %ld read from %s.\n",
>                  argv[1], pos, argv[2]);
>      }
>      else {
>           FILE *save_ftell = fopen(argv[2], "w");
>           if (!save_ftell ||
>               fseek(read_me, 5, SEEK_SET) != 0 ||
>               fprintf(save_ftell, "%ld\n", ftell(read_me)) != 2) {
>                fprintf(stderr, "Something went wrong!\n");
>                return EXIT_FAILURE;
>           }
>           printf("Seeked %s and saved the position in %s.\n", argv[1], argv[2]);
>      }
>      return EXIT_SUCCESS;
> }
> 

Ah, but you did an fseek().  You didn't just use the previous value
returned from ftell().  Of course this works.

Now do it without the fseek().

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web