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

[Nate Eldredge]

Jason <je******@gmail.comwrites:

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.

You want the "r+" mode.

[Jason]

On 13 Nov, 21:39, Nate Eldredge <[e-mail]:

Jason <[e-mail]:

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.

You want the "r+" mode.

Ah that simple, thanks very much works perfectly.

[Eric Sosman]

Jason wrote:

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?

Yes, for suitable file types (that is, for files that make
sense when accessed via "binary" rather than "text" streams).

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.

"Append" means "all new data goes at the end." If you want to
write data at some other spot, use "rb+" or "r+b", both of which
mean "open an existing file for reading (r) and update (+), in
binary mode (b)."

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");

Use "rb+", as noted above. Also, in a real program you should
check whether I/O operations succeed or fail, especially the fopen()
calls because they are particularly susceptible to failure.

fseek(cont, 0, SEEK_SET);

"2 bytes in," I think you said? Then why the zero? This seek
positions the stream at the very beginning of the file, not at at
the third byte.

fputs("T", cont);

This writes the single byte 'T', not the desired four bytes
of '\x1d'.

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.

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

[Joe Wright]

Jason wrote:

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

Try this..

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

int main(void) {
FILE *fp;
char *file = "jc.txt";
int c;

fp = fopen(file, "w");
fprintf(fp, "My name is jason.\n");
fclose(fp);

fp = fopen(file, "r");
while ((c = getc(fp)) != EOF) putchar(c);
fclose(fp);

fp = fopen(file, "r+");
fseek(fp, 11, SEEK_SET);
fputc('J', fp);
fclose(fp);

fp = fopen(file, "r");
while ((c = getc(fp)) != EOF) putchar(c);
fclose(fp);

return 0;
}

I've left the testing of fopen(), etc. up to you.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Antoninus Twink]

On 13 Nov 2008 at 21:43, Jason wrote:

On 13 Nov, 21:39, Nate Eldredge <[e-mail]:

>You want the "r+" mode.

Ah that simple, thanks very much works perfectly.

You may also want to do an fsync() (or fclose() of course) after writing
the data, to make sure it gets committed to disk.

[Keith Thompson]

Joe Wright <jo********@comcast.netwrites:

Jason wrote:

>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?

[...]

Try this..

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

int main(void) {
FILE *fp;
char *file = "jc.txt";
int c;

fp = fopen(file, "w");
fprintf(fp, "My name is jason.\n");
fclose(fp);

fp = fopen(file, "r");
while ((c = getc(fp)) != EOF) putchar(c);
fclose(fp);

fp = fopen(file, "r+");
fseek(fp, 11, SEEK_SET);
fputc('J', fp);
fclose(fp);

fp = fopen(file, "r");
while ((c = getc(fp)) != EOF) putchar(c);
fclose(fp);

return 0;
}

I've left the testing of fopen(), etc. up to you.

You almost certainly want to do this in binary mode.

--
Keith Thompson (The_Other_Keith) 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"

[Martien Verbruggen]

On Thu, 13 Nov 2008 17:27:24 -0500,
Joe Wright <jo********@comcast.netwrote:

Jason wrote:

>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?

Try this..

fp = fopen(file, "r+");
fseek(fp, 11, SEEK_SET);
fputc('J', fp);
fclose(fp);

To remain portable, the second argument of fseek() has to be 0 or a value
returned by a previous call to ftell(). You should probably open the
file in binary mode.

Martien
--
| Some people, when confronted with a problem,
Martien Verbruggen | think: "I know, I'll use regular
| expressions". Now they have two problems. --
| Jamie Zawinski

[Joe Wright]

Keith Thompson wrote:

Joe Wright <jo********@comcast.netwrites:

>Jason wrote:

>>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?

[...]

>Try this..

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

int main(void) {
FILE *fp;
char *file = "jc.txt";
int c;

fp = fopen(file, "w");
fprintf(fp, "My name is jason.\n");
fclose(fp);

fp = fopen(file, "r");
while ((c = getc(fp)) != EOF) putchar(c);
fclose(fp);

fp = fopen(file, "r+");
fseek(fp, 11, SEEK_SET);
fputc('J', fp);
fclose(fp);

fp = fopen(file, "r");
while ((c = getc(fp)) != EOF) putchar(c);
fclose(fp);

return 0;
}

I've left the testing of fopen(), etc. up to you.

You almost certainly want to do this in binary mode.

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

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Keith Thompson]

Joe Wright <jo********@comcast.netwrites:

Keith Thompson wrote:

>Joe Wright <jo********@comcast.netwrites:

>>Jason wrote:
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?

[...]

>>Try this..

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

int main(void) {
FILE *fp;
char *file = "jc.txt";
int c;

fp = fopen(file, "w");
fprintf(fp, "My name is jason.\n");
fclose(fp);

fp = fopen(file, "r");
while ((c = getc(fp)) != EOF) putchar(c);
fclose(fp);

fp = fopen(file, "r+");
fseek(fp, 11, SEEK_SET);
fputc('J', fp);
fclose(fp);

fp = fopen(file, "r");
while ((c = getc(fp)) != EOF) putchar(c);
fclose(fp);

return 0;
}

I've left the testing of fopen(), etc. up to you.

You almost certainly want to do this in binary mode.

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

For one thing, your fseek() call isn't guaranteed to be meaningful for
a text file; the behavior is undefined unless the offset is either
zero or a value obtained from an earlier call to ftell().

You'll probably get away with it if you (a) use fseek and ftell
carefully, and (b) avoid either overwriting or creating any new-lines,
but there could still be some issues.

On Unix-like systems, it doesn't make any difference; on Windows, a
new-line is represented as a two-character sequence, and other systems
have even stranger ways of representing lines in text files.

--
Keith Thompson (The_Other_Keith) 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"

[Eric Sosman]

Joe Wright wrote:

Keith Thompson wrote:

>Joe Wright <jo********@comcast.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 "HelloWworld" 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**@heliotrope.com.auwrites:

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

>Joe Wright wrote:

>>Keith Thompson wrote:
Joe Wright <jo********@comcast.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_Keith) 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**********************************@g17g2000prg. googlegroups.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*****@tango-sierrra.comwrites:

In article <77**********************************@g17g2000prg. googlegroups.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.orgwrote:

Martien Verbruggen <mg**@heliotrope.com.auwrites:

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

>>Joe Wright wrote:
Keith Thompson wrote:
Joe Wright <jo********@comcast.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**@heliotrope.com.auwrites:

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

>Martien Verbruggen <mg**@heliotrope.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_Keith) 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.orgwrote:

>
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.orgwrote:

>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.orgwrote:

>>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

[Phil Carmody]

Ian Collins <ia******@hotmail.comwrites:

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.orgwrote:

>>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.

What about the Oxford comma? OUP and Fowler both recommend its use.
The Guardian's neutral, advising its use if it would aid understanding.
I'm a Brit, and I'm very pro the Oxford comma; this is surprising, as
I tend to disagree with Fowler practically every time he's used as
support for some contruct.

Phil
--
I tried the Vista speech recognition by running the tutorial. I was
amazed, it was awesome, recognised every word I said. Then I said the
wrong word ... and it typed the right one. It was actually just
detecting a sound and printing the expected word! -- pbhj on /.

[Ben Bacarisse]

la************@siemens.com writes:

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.orgwrote:

>>
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.

To me, the most compelling argument is that if the other meaning were
intended the restriction on whence would surely come first: "For a
text stream, whence shall be SEEK_SET and either offset shall be zero
or offset shall be a value returned by a ...".

I think you can get rid of any trace of an alternate parse simply by
putting the whence restriction sooner:

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

Now any attempt to make the "and offset shall be a value..." clause
apply to both parts of the preceding "or" results in a double
restriction on offset (it shall be zero and the result of ftell).
Readers naturally avoid such illogical parses.

I don't think the original is ambiguous, but it seems to have proved to
be so despite careful punctuation!

--
Ben.

[Keith Thompson]

Ben Bacarisse <be********@bsb.me.ukwrites:
[...]

To me, the most compelling argument is that if the other meaning were
intended the restriction on whence would surely come first: "For a
text stream, whence shall be SEEK_SET and either offset shall be zero
or offset shall be a value returned by a ...".

[...]

Better yet, "For a text stream, whence shall be SEEK_SET and offset
shall be either zero or a value returned by a ...".

(And yes, I'd probably put a comma after SEEK_SET.)

--
Keith Thompson (The_Other_Keith) 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]

Ian Collins <ia******@hotmail.comwrote:

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

The standard does use serial commas, but the usage we're discussing
(mixed "and" and "or" clauses) isn't really serial.
--
Larry Jones

This sounds suspiciously like one of Dad's plots to build my character.
-- Calvin

[lawrence.jones]

Ben Bacarisse <be********@bsb.me.ukwrote:

>
I think you can get rid of any trace of an alternate parse simply by
putting the whence restriction sooner:

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

That's better, but I think it would be better still to capture the "and"
between the "either" and the "or":

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

What a waste to be going to school on a morning like this. -- Calvin

[Ian Collins]

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

Ian Collins <ia******@hotmail.comwrote:

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

The standard does use serial commas, but the usage we're discussing
(mixed "and" and "or" clauses) isn't really serial.

Is there a standard or guidelines for the language in ISO standards?

--
Ian Collins

[Ben Bacarisse]

la************@siemens.com writes:

Ben Bacarisse <be********@bsb.me.ukwrote:

>>
I think you can get rid of any trace of an alternate parse simply by
putting the whence restriction sooner:

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

That's better, but I think it would be better still to capture the "and"
between the "either" and the "or":

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

That does not works so well to my mind -- maybe simply because of the
of two short phases with such a long one in the middle. It seems
harder to hold them meaning until it is all resolved. However, I am
biased!

--
Ben.

[lawrence.jones]

Ian Collins <ia******@hotmail.comwrote:

>
Is there a standard or guidelines for the language in ISO standards?

Part 2 of the ISO/IEC Directives (Rules for the structure and drafting
of International Standard) provides some guidelines.
--
Larry Jones

I thought my life would seem more interesting with a musical
score and a laugh track. -- Calvin