File Seeking / Overwriting bytes

[Jason]

Hi,

I need to open an existing file, seek to a position at X number of
bytes, and write out Y number of bytes overwriting any existing bytes,
but no erasing any other data. Is this possible?

I've opened a file in append "a" mode, and then used fseek with
SEEK_SET to seek to 0 bytes into the file, but this sets the position
at the end of existing data, not actually at the start of the file.

So say I have a file of 8 bytes: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF
I want to open it, seek to a specific offset, lets say 2 bytes in,
then write out 4 bytes with the value 1D overwriting existing bytes,
leaving the file with: 0xFF 0xFF 0x1D 0x1D 0x1D 0x1D 0xFF 0xFF

Heres my testing code.

FILE *cont;
cont = fopen("/home/jk/test.txt", "a");
fseek(cont, 0, SEEK_SET);
fputs("T", cont);
fclose(cont);
Please can someone point me in the right direction, I want to avoid
reading everything in, editing it and rewriting it all out because the
file could be huge.

Many thanks,
Jason

[Eric Sosman]

Joe Wright wrote:

Keith Thompson wrote:

>Joe Wright <jo********@com cast.netwrites:

>>Try this..
[... see up-thread ...]

You almost certainly want to do this in binary mode.

It never occurred to me. Why on earth use binary mode?

To be sure the fseek() will work. On a text stream, you
can only fseek() to a position you've already recorded with
ftell(), or to the very beginning or the very end. You can't
just leap to an arbitrary byte position, because a text stream
may need to translate between internal and external forms, andß
the forms may not be of equal length.

One commonly-encountered translation involves line endings.
When you write "Hello\nworld!\ n" to a text stream, some systems
actually write "Hello\r\nworld !\r\n" to the output file. You
may think that the 'w' is at offset six -- after all, you wrote
exactly six characters before it -- but it turns out that the
'w' is actually at offset seven because the single '\n' character
you wrote was translated to '\r' '\n' in the file. If you manage
to seek to offset six and plant a 'W' there, you might read back
"Hello\rWworld\ n" or "HelloWworl d" or you might not even be able
to read the data at all.

Less frequently encountered translations crop up occasionally.
Some character encoding schemes use "shifts" or "escapes" to record
supplementary characters, so if you write the single character 'ß',
say, you might get something like '\x0e' '\x5f' '\x0f', meaning
"switch to alternate character set, interpret 5F as a character of
that alternate set instead of as an underscore, shift back to the
normal character set." (The example is intended only to show the
nature of such schemes; the details need not be taken literally.)
So your single 'ß' winds up occupying three bytes in the file, and
if you seek to the spot you imagine is just after it you'll wind
up at what looks like the 5F underscore, in the middle of the three-
byte sequence that represents your single character. Not Good.

Anyhow: If you need to seek to calculated positions, you
need to use a binary stream to do it reliably. In a text stream
you can return to a place you've already been (and remembered),
but you can't navigate by de'd reckoning.

--
Er*********@sun .com

[Keith Thompson]

Martien Verbruggen <mg**@heliotrop e.com.auwrites:

On Thu, 13 Nov 2008 18:24:04 -0500,
Eric Sosman <Er*********@su n.comwrote:

>Joe Wright wrote:

>>Keith Thompson wrote:
Joe Wright <jo********@com cast.netwrites:
Try this..
[... see up-thread ...]

You almost certainly want to do this in binary mode.

It never occurred to me. Why on earth use binary mode?

To be sure the fseek() will work. On a text stream, you
can only fseek() to a position you've already recorded with
ftell(), or to the very beginning or the very end.

I don't think SEEK_END, which I assume you'd use to position at the end,
is supported on text streams.

C99: 7.19.9.2 - 4

4 For a text stream, either offset shall be zero, or offset shall be a
value returned by an earlier successful call to the ftell function on
a stream associated with the same file and whence shall be SEEK_SET.

I don't have a C90 standard, but a pre-standard draft has identical
wording to the above, so I assume the standard contains that wording as
well.

The wording you quoted implies that seeking to the end *is* allowed.
Valid calls are:

fseek(f, 0, SEEK_SET);
fseek(f, 0, SEEK_CUR);
fseek(f, 0, SEEK_END);
fseek(f, n, SEEK_SET);

where n was returned by a previous call to ftell() on the same file.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[S M Ryan]

In article <77************ *************** *******@g17g200 0prg.googlegrou ps.com>,
Jason <je******@gmail .comwrote:

Hi,

I need to open an existing file, seek to a position at X number of
bytes, and write out Y number of bytes overwriting any existing bytes,
but no erasing any other data. Is this possible?

In character mode it depends on the operating system. Unices will do what you
want, but it's not required that any system do so.

I've opened a file in append "a" mode, and then used fseek with
SEEK_SET to seek to 0 bytes into the file, but this sets the position
at the end of existing data, not actually at the start of the file.

That's what "a" mode does. It always writes at the end regardless of where the
file might be positioned. You need something like "w", "w+", or "r+".

Please can someone point me in the right direction, I want to avoid
reading everything in, editing it and rewriting it all out because the
file could be huge.

On modern systems that might actually be as cheap as anything else.

--
I'm not even supposed to be here today.

I ASSURE YOU WE'RE OPEN!

[Nate Eldredge]

S M Ryan <wy*****@tang o-sierrra.comwrit es:

In article <77************ *************** *******@g17g200 0prg.googlegrou ps.com>,
Jason <je******@gmail .comwrote:

>Please can someone point me in the right direction, I want to avoid
reading everything in, editing it and rewriting it all out because the
file could be huge.

On modern systems that might actually be as cheap as anything else.

What systems are those?

[Martien Verbruggen]

On Thu, 13 Nov 2008 16:52:06 -0800,
Keith Thompson <ks***@mib.orgw rote:

Martien Verbruggen <mg**@heliotrop e.com.auwrites:

>On Thu, 13 Nov 2008 18:24:04 -0500,
Eric Sosman <Er*********@su n.comwrote:

>>Joe Wright wrote:
Keith Thompson wrote:
Joe Wright <jo********@com cast.netwrites:
>Try this..
> [... see up-thread ...]
>
You almost certainly want to do this in binary mode.
>
It never occurred to me. Why on earth use binary mode?

To be sure the fseek() will work. On a text stream, you
can only fseek() to a position you've already recorded with
ftell(), or to the very beginning or the very end.

I don't think SEEK_END, which I assume you'd use to position at the end,
is supported on text streams.

C99: 7.19.9.2 - 4

4 For a text stream, either offset shall be zero, or offset shall be a
value returned by an earlier successful call to the ftell function on
a stream associated with the same file and whence shall be SEEK_SET.

I don't have a C90 standard, but a pre-standard draft has identical
wording to the above, so I assume the standard contains that wording as
well.

The wording you quoted implies that seeking to the end *is* allowed.
Valid calls are:

fseek(f, 0, SEEK_SET);
fseek(f, 0, SEEK_CUR);
fseek(f, 0, SEEK_END);
fseek(f, n, SEEK_SET);

where n was returned by a previous call to ftell() on the same file.

I see... There are two possible readings there, depending on what
'whence shall be SEEK_SET' is linked to...

(offset == 0) or (offset == fseek value and whence == SEEK_SET)

or

(offset == 0 or offset == fseek value) and whence == SEEK_SET

In a programming language we heve precedence or grammar rules that tell
us which interpretation is the right one. English doesn't really ave
that. The presence or absence of a comma after 'and' IMO is not enough.

is there a ruling somewhere that makes clear which of these two
interpretations was the intended one? I find it har dto believe that
this hasn't popped up before 9and if it has, why wasn't it made less
ambiguous? Or am I the only one who thinks it is ambiguous?)
Martien
--
|
Martien Verbruggen | If at first you don't succeed, try again.
| Then quit; there's no use being a damn fool
| about it.

[Keith Thompson]

Martien Verbruggen <mg**@heliotrop e.com.auwrites:

On Thu, 13 Nov 2008 16:52:06 -0800,
Keith Thompson <ks***@mib.orgw rote:

>Martien Verbruggen <mg**@heliotrop e.com.auwrites:

[...]

>>I don't think SEEK_END, which I assume you'd use to position at the end,
is supported on text streams.

C99: 7.19.9.2 - 4

4 For a text stream, either offset shall be zero, or offset shall be a
value returned by an earlier successful call to the ftell function on
a stream associated with the same file and whence shall be SEEK_SET.

I don't have a C90 standard, but a pre-standard draft has identical
wording to the above, so I assume the standard contains that wording as
well.

The wording you quoted implies that seeking to the end *is* allowed.
Valid calls are:

fseek(f, 0, SEEK_SET);
fseek(f, 0, SEEK_CUR);
fseek(f, 0, SEEK_END);
fseek(f, n, SEEK_SET);

where n was returned by a previous call to ftell() on the same file.

I see... There are two possible readings there, depending on what
'whence shall be SEEK_SET' is linked to...

(offset == 0) or (offset == fseek value and whence == SEEK_SET)

or

(offset == 0 or offset == fseek value) and whence == SEEK_SET

In a programming language we heve precedence or grammar rules that tell
us which interpretation is the right one. English doesn't really ave
that. The presence or absence of a comma after 'and' IMO is not enough.

is there a ruling somewhere that makes clear which of these two
interpretations was the intended one? I find it har dto believe that
this hasn't popped up before 9and if it has, why wasn't it made less
ambiguous? Or am I the only one who thinks it is ambiguous?)

I didn't find it ambiguous until you mentioned it. 8-)}

For the second interpretation, I think there would have to be a comma
after "the same file".

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[lawrence.jones]

In regards to C99: 7.19.9.2p4:

For a text stream, either offset shall be zero, or offset shall
be a value returned by an earlier successful call to the ftell
function on a stream associated with the same file and whence
shall be SEEK_SET.

Keith Thompson <ks***@mib.orgw rote:

>
I didn't find it ambiguous until you mentioned it. 8-)}

For the second interpretation, I think there would have to be a comma
after "the same file".

And no comma after "offset shall be zero". Because English doesn't have
grouping operators, the standard is very carefully punctuated and also
makes judicious use of words like "either" and "both" to indicate the
correct parsing.
--
Larry Jones

Let's pretend I already feel terrible about it, and that you
don't need to rub it in any more. -- Calvin

[Ian Collins]

la************@ siemens.com wrote:

In regards to C99: 7.19.9.2p4:

For a text stream, either offset shall be zero, or offset shall
be a value returned by an earlier successful call to the ftell
function on a stream associated with the same file and whence
shall be SEEK_SET.

Keith Thompson <ks***@mib.orgw rote:

>I didn't find it ambiguous until you mentioned it. 8-)}

For the second interpretation, I think there would have to be a comma
after "the same file".

And no comma after "offset shall be zero". Because English doesn't have
grouping operators, the standard is very carefully punctuated and also
makes judicious use of words like "either" and "both" to indicate the
correct parsing.

In non-American English commas are seldom, if ever, placed before an and.

--
Ian Collins

[Richard Heathfield]

Ian Collins said:

la************@ siemens.com wrote:

>In regards to C99: 7.19.9.2p4:

For a text stream, either offset shall be zero, or offset shall
be a value returned by an earlier successful call to the ftell
function on a stream associated with the same file and whence
shall be SEEK_SET.

Keith Thompson <ks***@mib.orgw rote:

>>I didn't find it ambiguous until you mentioned it. 8-)}

For the second interpretation, I think there would have to be a comma
after "the same file".

And no comma after "offset shall be zero". Because English doesn't have
grouping operators, the standard is very carefully punctuated and also
makes judicious use of words like "either" and "both" to indicate the
correct parsing.

In non-American English commas are seldom, if ever, placed before an and.

I am not American, and I certainly don't use American English. Nevertheless
I often find myself using a comma immediately before an "and", and
sometimes afterwards as well(!), and none of my English teachers at school
ever objected, and this was in the days when most of the books I read were
written, and published, in the UK, and even those that did come from the
USA were "anglicised " (i.e. all the punctuation, grammar, and spelling was
translated back into English), and this, I hope, shows that my education
was not affected by US usage.

The above paragraph is obviously rather artificial, but it doesn't contain
any grammar that I would be unhappy using in my capacity as Englishman.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Ian Collins]

Richard Heathfield wrote:

Ian Collins said:

>In non-American English commas are seldom, if ever, placed before an and.

I am not American, and I certainly don't use American English. Nevertheless
I often find myself using a comma immediately before an "and", and
sometimes afterwards as well(!), and none of my English teachers at school
ever objected, and this was in the days when most of the books I read were
written, and published, in the UK, and even those that did come from the
USA were "anglicised " (i.e. all the punctuation, grammar, and spelling was
translated back into English), and this, I hope, shows that my education
was not affected by US usage.

The above paragraph is obviously rather artificial, but it doesn't contain
any grammar that I would be unhappy using in my capacity as Englishman.

http://en.wikipedia.org/wiki/Serial_comma a fairly balanced account.

--
Ian Collins