O_TEXT, in microsoft environment

[O_TEXT]

When opening a file with open and O_TEXT, in microsoft environment, and
then reading it with read, it is done in text mode.

What does text mode exactly mean?

How is it handled in reading?

How is it handled in writing?

does text mode has an impact on function returning position within the
file? If yes, which one?

[jacob navia]

O_TEXT wrote:

When opening a file with open and O_TEXT, in microsoft environment, and
then reading it with read, it is done in text mode.

What does text mode exactly mean?

How is it handled in reading?

How is it handled in writing?

does text mode has an impact on function returning position within the
file? If yes, which one?

DO YOUR OWN HOMEWORK!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Malcolm McLean]

"O_TEXT" <O_****@nospam.frwrote in message
news:fh***********@biggoron.nerim.net...

When opening a file with open and O_TEXT, in microsoft environment, and
then reading it with read, it is done in text mode.

What does text mode exactly mean?

How is it handled in reading?

How is it handled in writing?

does text mode has an impact on function returning position within the
file? If yes, which one?

If you are printing out on an old-fashioned line printer you need to tell
the printer to move down to the next line, and also to return.
However if you are typing on a modern keyboard, usually the return button
will automatically move the cursor to the next line.
So the question is whether to represent newlines as "\n" or "\n\r".
Operating systems make different choices. However ANSI C has decided that
the "\n", or newline only route, will be used. So if you open a file in text
mode on an "\r\n" operating system the "\r" will be silently suppressed.
This is only good for files that actually represent text. Binary files might
have "\n\r" sequences embedded in them purely by chance.

So in the standard library we use

fopen(filename, "r");

to open in text mode for reading

fopen(filename, "rb")

to open in binary mode.

O_TEXT is just an alternative interface Microsoft have provided to the same
underlying system

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[O_TEXT]

Malcolm McLean a écrit :

>
"O_TEXT" <O_****@nospam.frwrote in message
news:fh***********@biggoron.nerim.net...

>When opening a file with open and O_TEXT, in microsoft environment,
and then reading it with read, it is done in text mode.

What does text mode exactly mean?

How is it handled in reading?

How is it handled in writing?

does text mode has an impact on function returning position within the
file? If yes, which one?

If you are printing out on an old-fashioned line printer you need to
tell the printer to move down to the next line, and also to return.
However if you are typing on a modern keyboard, usually the return
button will automatically move the cursor to the next line.
So the question is whether to represent newlines as "\n" or "\n\r".
Operating systems make different choices. However ANSI C has decided
that the "\n", or newline only route, will be used. So if you open a
file in text mode on an "\r\n" operating system the "\r" will be
silently suppressed.
This is only good for files that actually represent text. Binary files
might have "\n\r" sequences embedded in them purely by chance.

So in the standard library we use

fopen(filename, "r");

to open in text mode for reading

fopen(filename, "rb")

to open in binary mode.

O_TEXT is just an alternative interface Microsoft have provided to the
same underlying system

okay, I understand the \r\n -\n translation mechanism.

But what I do not understand is whether read and lseek values are bytes
offset or character offset.

If you read 4096 bytes which contain 3900 translated characters, will
read return 4096 or 3900? what's about lseek?

[O_TEXT]

jacob navia a écrit :

O_TEXT wrote:

>When opening a file with open and O_TEXT, in microsoft environment,
and then reading it with read, it is done in text mode.

What does text mode exactly mean?

How is it handled in reading?

How is it handled in writing?

does text mode has an impact on function returning position within the
file? If yes, which one?

DO YOUR OWN HOMEWORK!

Malcom provides a better answer.

your answer is useless.
Moreover, you should learn keyboards contain a key which allow typing
non capitalized characters.

[Charlie Gordon]

"O_TEXT" <O_****@nospam.fra écrit dans le message de news:
fh***********@biggoron.nerim.net...

Malcolm McLean a écrit :

>>
"O_TEXT" <O_****@nospam.frwrote in message
news:fh***********@biggoron.nerim.net...

>>When opening a file with open and O_TEXT, in microsoft environment, and
then reading it with read, it is done in text mode.

What does text mode exactly mean?

How is it handled in reading?

How is it handled in writing?

does text mode has an impact on function returning position within the
file? If yes, which one?

If you are printing out on an old-fashioned line printer you need to tell
the printer to move down to the next line, and also to return.
However if you are typing on a modern keyboard, usually the return button
will automatically move the cursor to the next line.
So the question is whether to represent newlines as "\n" or "\n\r".
Operating systems make different choices. However ANSI C has decided that
the "\n", or newline only route, will be used. So if you open a file in
text mode on an "\r\n" operating system the "\r" will be silently
suppressed.
This is only good for files that actually represent text. Binary files
might have "\n\r" sequences embedded in them purely by chance.

So in the standard library we use

fopen(filename, "r");

to open in text mode for reading

fopen(filename, "rb")

to open in binary mode.

O_TEXT is just an alternative interface Microsoft have provided to the
same underlying system

okay, I understand the \r\n -\n translation mechanism.

But what I do not understand is whether read and lseek values are bytes
offset or character offset.

If you read 4096 bytes which contain 3900 translated characters, will read
return 4096 or 3900? what's about lseek?

This is highly Microsoft specific. You are referring to non standard
low-level I/O. You will get a more accurate answer from a microsoft
specific forum.

--
Chqrlie.

[Mark Bluemel]

O_TEXT wrote:

When opening a file with open and O_TEXT, in microsoft environment, and
then reading it with read, it is done in text mode.

If you want to know about microsoft specifics, there are probably more
appropriate groups in which to ask. We tend to concentrate on the C
language as defined by the ISO standard, rather than platform-specific
features.

What does text mode exactly mean?

If O_TEXT means opening in what the standard defines as a text stream,
it means what the standard says...

How is it handled in reading?
How is it handled in writing?

The standard says that that is implementation-defined, as I understand it.

does text mode has an impact on function returning position within the
file? If yes, which one?

The standard only provides one such function - ftell() - and defines it
as producing, in effect, "opaque" data for text streams. By this I mean
that the value can be used by fseek() on the same stream but has no
externally-meaningful value.

[Charlie Gordon]

"O_TEXT" <O_****@nospam.fra écrit dans le message de news:
fh***********@biggoron.nerim.net...

jacob navia a écrit :

>O_TEXT wrote:

>>When opening a file with open and O_TEXT, in microsoft environment, and
then reading it with read, it is done in text mode.

What does text mode exactly mean?

How is it handled in reading?

How is it handled in writing?

does text mode has an impact on function returning position within the
file? If yes, which one?

DO YOUR OWN HOMEWORK!

Malcom provides a better answer.

It's Malcolm actually.
But names don't matter do they O_TEXT ?

your answer is useless.

You should begin your phrases with a capital letter.

Moreover, you should learn keyboards contain a key which allow typing non
capitalized characters.

Keyboards do not "contain" keys.

Your question is probably not homework, but it is O/S specific. It is too
bad you were rude to Jacob, for he could have given you detailed answer,
Windows being his platform of choice.

--
Chqrlie.

[Richard Heathfield]

Charlie Gordon said:

<snip>

Your question is probably not homework, but it is O/S specific. It is
too bad you were rude to Jacob,

Yes indeed - and it was also too bad that Jacob was rude to him.

for he could have given you detailed
answer, Windows being his platform of choice.

Yes, but then C is his language of choice. Just because <foois your <bar>
of choice, that doesn't make you an expert <foo>er.

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

[Charlie Gordon]

"Richard Heathfield" <rj*@see.sig.invalida écrit dans le message de news:
o4******************************@bt.com...

Charlie Gordon said:

<snip>

>Your question is probably not homework, but it is O/S specific. It is
too bad you were rude to Jacob,

Yes indeed - and it was also too bad that Jacob was rude to him.

>for he could have given you detailed
answer, Windows being his platform of choice.

Yes, but then C is his language of choice. Just because <foois your
<bar>
of choice, that doesn't make you an expert <foo>er.

I used to waste my energy programming on DOS around these stupid Microsoft
specific text mode hacks. I even rewrote a C I/O library because I was
disgusted to see them do the \r\n translation at the low level interface
instead of just the stdio level. The benefits of bufferization were lost
because of this, as the low level I/O was not done on nice round aligned
blocks, leading to general slugishness.

I have since given up on this broken platform, and focus my development
efforts on Linux, only occasionally porting stuff to MingW or Cygwin.

Jacob makes a Windows based C compiler. He is certainly more up to date on
this issue than I am, and more an expert at it than most regulars on this
forum. Your constant bashing of his abilities is tiresome and provocative.
He makes mistakes, you make mistakes, I make mistakes, we all do, both on
technical issues and on communication skills. We are all on the same side
here, defending our language of choice, let's reserve our attacks for all
the crud out there that deserves it: java and C++ bloatware from all the big
names, MSFT and ORCL leading the pack...

--
Chqrlie.

[O_TEXT]

Charlie Gordon a écrit :

"Richard Heathfield" <rj*@see.sig.invalida écrit dans le message de news:
o4******************************@bt.com...

>Charlie Gordon said:

<snip>

>>Your question is probably not homework, but it is O/S specific. It is
too bad you were rude to Jacob,

Yes indeed - and it was also too bad that Jacob was rude to him.

>>for he could have given you detailed
answer, Windows being his platform of choice.

Yes, but then C is his language of choice. Just because <foois your
<bar>
of choice, that doesn't make you an expert <foo>er.

I used to waste my energy programming on DOS around these stupid Microsoft
specific text mode hacks. I even rewrote a C I/O library because I was
disgusted to see them do the \r\n translation at the low level interface
instead of just the stdio level. The benefits of bufferization were lost
because of this, as the low level I/O was not done on nice round aligned
blocks, leading to general slugishness.

I have since given up on this broken platform, and focus my development
efforts on Linux, only occasionally porting stuff to MingW or Cygwin.

Jacob makes a Windows based C compiler. He is certainly more up to date on
this issue than I am, and more an expert at it than most regulars on this
forum. Your constant bashing of his abilities is tiresome and provocative.
He makes mistakes, you make mistakes, I make mistakes, we all do, both on
technical issues and on communication skills. We are all on the same side
here, defending our language of choice, let's reserve our attacks for all
the crud out there that deserves it: java and C++ bloatware from all the big
names, MSFT and ORCL leading the pack...

I agree with you.
I am sorry if I have hurt somebody. I am sorry if I do not write your
language as well as you do.

What I'd like to do is understand how the stdio and io library from crt
from reactos (does not?) works. For this I needed finding some
information on what original microsoft behavior was.

I fastly searched on internet and did not found.
I just asked in microsoft public vc language; is this an appropriate forum?

[O_TEXT]

Mark Bluemel a écrit :

O_TEXT wrote:

>When opening a file with open and O_TEXT, in microsoft environment,
and then reading it with read, it is done in text mode.

If you want to know about microsoft specifics, there are probably more
appropriate groups in which to ask. We tend to concentrate on the C
language as defined by the ISO standard, rather than platform-specific
features.

Yes, which one?

>What does text mode exactly mean?

If O_TEXT means opening in what the standard defines as a text stream,
it means what the standard says...

Is the standard available at a known URL?

>How is it handled in reading?
How is it handled in writing?

The standard says that that is implementation-defined, as I understand it.

>does text mode has an impact on function returning position within the
file? If yes, which one?

The standard only provides one such function - ftell() - and defines it
as producing, in effect, "opaque" data for text streams. By this I mean
that the value can be used by fseek() on the same stream but has no
externally-meaningful value.

okay.

ftell is from stdio level, isn't it? (I mean it is not from same level
as lseek read write and open).

Does not lseek (with parameter 0 and SEEK_CUR) provide same kind of
functionality?
I had three other subsidiaries questions:

Does read takes as input buffer size in bytes and gives as output number
of readen characters?

Will lseek take number of bytes to move to or number of characters?

If I write a new line character in an existing text file, will the
behavior be deterministic in some way? Will this change the three bytes
file from "x\r\n" to "\r\n\n"?

[Richard]

"Charlie Gordon" <ne**@chqrlie.orgwrites:

"Richard Heathfield" <rj*@see.sig.invalida écrit dans le message de news:
o4******************************@bt.com...

>Charlie Gordon said:

<snip>

>>Your question is probably not homework, but it is O/S specific. It is
too bad you were rude to Jacob,

Yes indeed - and it was also too bad that Jacob was rude to him.

>>for he could have given you detailed
answer, Windows being his platform of choice.

Yes, but then C is his language of choice. Just because <foois your
<bar>
of choice, that doesn't make you an expert <foo>er.

I used to waste my energy programming on DOS around these stupid Microsoft
specific text mode hacks. I even rewrote a C I/O library because I was
disgusted to see them do the \r\n translation at the low level interface
instead of just the stdio level. The benefits of bufferization were lost
because of this, as the low level I/O was not done on nice round aligned
blocks, leading to general slugishness.

I have since given up on this broken platform, and focus my development
efforts on Linux, only occasionally porting stuff to MingW or Cygwin.

Jacob makes a Windows based C compiler. He is certainly more up to date on
this issue than I am, and more an expert at it than most regulars on this
forum. Your constant bashing of his abilities is tiresome and
provocative.

Well said. He comes across as a spiteful and bitter. I simply don't know
why he can not reign himself in as his C knowledge is generally better
than most. Unfortunately a small clique have oiled each other up so much
for the past while, that a small core element really do think they own
this newsgroup. One rule for them and another rule for others.

He makes mistakes, you make mistakes, I make mistakes, we all do, both on
technical issues and on communication skills. We are all on the same side
here, defending our language of choice, let's reserve our attacks for all
the crud out there that deserves it: java and C++ bloatware from all the big
names, MSFT and ORCL leading the pack...

[Richard Heathfield]

Charlie Gordon said:

Your constant bashing of his abilities is tiresome and
provocative.

I have never bashed his abilities, only his apparent *in*ability to learn
from his mistakes.

He makes mistakes, you make mistakes, I make mistakes, we
all do, both on
technical issues and on communication skills.

Right. When you make a mistake, you are generally quick to recognise it,
and even when you aren't so quick to do that, you make an effort to
understand what your critic is getting at. Well done you!

We are all on the same side here,

I'm not convinced.

defending our language of choice,

Oh, that isn't the side I'm on. If people want to use something else, let
them. I'm not here to defend C, but to help people to learn it. Part of
helping people to learn C involves pointing out mistakes made not just by
the OP but by those who respond to him. But I have made a conscious effort
(not always successfully) to resist replying to Jacob Navia's articles in
recent months, despite the large number of mistakes he makes, simply
because such discussions tend to generate more heat than light. Since few
others here want to attract the kind of flak that I get from him, the
result is that many of his mistakes go uncorrected. This is not good for
the OPs or for the group.

let's reserve our attacks
for all the crud out there that deserves it:

I'll make you a deal. If you will personally undertake to post corrections
to all the mistakes Jacob Navia makes in this group, I'll never so much as
mention his name again. Fair?

java and C++ bloatware from
all the big names, MSFT and ORCL leading the pack...

I see no reason to attack Java or C++ in a C newsgroup. If people want to
find out how good or how bad those technologies are, comp.lang.c is hardly
the right place to do it.

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

[Kenneth Brody]

O_TEXT wrote:
[...]

So in the standard library we use

fopen(filename, "r");

to open in text mode for reading

fopen(filename, "rb")

to open in binary mode.

O_TEXT is just an alternative interface Microsoft have provided to the
same underlying system

okay, I understand the \r\n -\n translation mechanism.

But what I do not understand is whether read and lseek values are bytes
offset or character offset.

If you read 4096 bytes which contain 3900 translated characters, will
read return 4096 or 3900? what's about lseek?

Well, open/read/lseek are not part of standard C. However, the
same discussion applies to text mode of fopen/fread/fseek.

I will use MS-Windows as an example, and any specific numbers are
implementation-specific. However, the ideas are cross-platform.

Suppose you have a file containing the following 10 characters:

'a' 'b' 'c' '\r' '\n' '1' '2' '3' '\r' '\n'

If the file is fopened in text mode, and you call fread() with a
length of 5, you will be returned the following 5 characters,
and fread() will tell you that you read 5 characters:

'a' 'b' 'c' '\n' '1'

Note that you get the '1' from the second line of the file. This
is because you requested 5 characters, and there were 5 available.
Note, too, that although 5 characters were returned, you have
advanced 6 characters within the file.

If you were to call ftell(), it would tell you that you were at
position 6 in the file, despite having read only 5 characters.

If you were to later fseek() to the value returned from ftell(),
you would be positioned where you were before -- at the '2'.

However, if you were to assume that, having read 5 characters,
and passed the offset 5 to fseek() (which, as I recall, is not
"legal", as it's not a value returned from ftell), you would
be positioned elsewhere -- at the '1'.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Tor Rustad]

O_TEXT wrote:

When opening a file with open and O_TEXT, in microsoft environment, and
then reading it with read, it is done in text mode.

Check out the standard C functions instead:

fopen, fread, fwrite, fclose

--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>

[Malcolm McLean]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message

I see no reason to attack Java or C++ in a C newsgroup. If people want to
find out how good or how bad those technologies are, comp.lang.c is hardly
the right place to do it.

C++ is a near superset of C. So if we are going to justify use of C at all,
that implies some criticism of C++.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Richard Heathfield]

Malcolm McLean said:

>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message

>I see no reason to attack Java or C++ in a C newsgroup. If people want
to find out how good or how bad those technologies are, comp.lang.c is
hardly the right place to do it.

C++ is a near superset of C. So if we are going to justify use of C at
all, that implies some criticism of C++.

I don't think that's true, any more than the decision to use a teaspoon to
stir tea implies criticism of dessert spoons.

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

[Mark McIntyre]

On Sun, 11 Nov 2007 10:33:53 -0000, in comp.lang.c , "Malcolm McLean"
<re*******@btinternet.comwrote:

>C++ is a near superset of C. So if we are going to justify use of C at all,
that implies some criticism of C++.

That's a nonsensical argument. The superset of earth moving devices
includes ocean-going dredgers, but using a hand-trowel to dig your
window box does not imply any criticism of dredgers.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Richard Tobin]

In article <r0********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:

>>C++ is a near superset of C. So if we are going to justify use of C at all,
that implies some criticism of C++.

>That's a nonsensical argument. The superset of earth moving devices
includes ocean-going dredgers, but using a hand-trowel to dig your
window box does not imply any criticism of dredgers.

Neither this nor Richard Heathfield's reply are accurate enough
analogies to refute the claim. A dredger is not a superset of a
hand-trowel. A dessert spoon is not a superset of a teaspoon.

-- Richard

--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Richard Heathfield]

Richard Tobin said:

In article <r0********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:

>>>C++ is a near superset of C. So if we are going to justify use of C at
all, that implies some criticism of C++.

>>That's a nonsensical argument. The superset of earth moving devices
includes ocean-going dredgers, but using a hand-trowel to dig your
window box does not imply any criticism of dredgers.

Neither this nor Richard Heathfield's reply are accurate enough
analogies to refute the claim. A dredger is not a superset of a
hand-trowel. A dessert spoon is not a superset of a teaspoon.

Okay, so we need a better illustration. How about this one? The reals are
not just a near superset, but a genuinely "proper" superset, of the
rationals. Nevertheless, using rationals in calculations does not imply
criticism of the reals.

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

[Charlie Gordon]

"Richard Heathfield" <rj*@see.sig.invalida écrit dans le message de news:
ra******************************@bt.com...

Charlie Gordon said:

>Your constant bashing of his abilities is tiresome and
provocative.

I have never bashed his abilities, only his apparent *in*ability to learn
from his mistakes.

No, you are not. You often use irony in an offensive way that goes well
beyond this claim.

>He makes mistakes, you make mistakes, I make mistakes, we
all do, both on
technical issues and on communication skills.

Right. When you make a mistake, you are generally quick to recognise it,
and even when you aren't so quick to do that, you make an effort to
understand what your critic is getting at. Well done you!

Thank you. But I think you are even more stubborn than he is when it comes
to recognizing your errors, or even just amending your position.

>We are all on the same side here,

I'm not convinced.

>defending our language of choice,

Oh, that isn't the side I'm on. If people want to use something else, let
them. I'm not here to defend C, but to help people to learn it. Part of
helping people to learn C involves pointing out mistakes made not just by
the OP but by those who respond to him. But I have made a conscious effort
(not always successfully) to resist replying to Jacob Navia's articles in
recent months, despite the large number of mistakes he makes, simply
because such discussions tend to generate more heat than light. Since few
others here want to attract the kind of flak that I get from him, the
result is that many of his mistakes go uncorrected. This is not good for
the OPs or for the group.

Extreme conservatism is also counterproductive for the OPs and confines to
pedantry. Confusing newbies with the intricacies of non two's complement
representations or padding bits and trap values is, IMHO, useless display of
pedantry.

>let's reserve our attacks
for all the crud out there that deserves it:

I'll make you a deal. If you will personally undertake to post corrections
to all the mistakes Jacob Navia makes in this group, I'll never so much as
mention his name again. Fair?

Fair. I will just not be as quick to jump on my keyboard as you are, time
not permitting.

>java and C++ bloatware from
all the big names, MSFT and ORCL leading the pack...

I see no reason to attack Java or C++ in a C newsgroup. If people want to
find out how good or how bad those technologies are, comp.lang.c is hardly
the right place to do it.

Attacks are not necessary, irony will suffice.

--
Chqrlie.

[Richard Heathfield]

Charlie Gordon said:

"Richard Heathfield" <rj*@see.sig.invalida écrit dans le message de
news: ra******************************@bt.com...

>Charlie Gordon said:

>>Your constant bashing of his abilities is tiresome and
provocative.

I have never bashed his abilities, only his apparent *in*ability to
learn from his mistakes.

No, you are not. You often use irony in an offensive way that goes well
beyond this claim.

Well, I disagree.

>>He makes mistakes, you make mistakes, I make mistakes, we
all do, both on
technical issues and on communication skills.

Right. When you make a mistake, you are generally quick to recognise it,
and even when you aren't so quick to do that, you make an effort to
understand what your critic is getting at. Well done you!

Thank you. But I think you are even more stubborn than he is when it
comes to recognizing your errors, or even just amending your position.

Perhaps we can agree to disagree about that. I try hard to own up to my own
errors as soon as possible, partly because it's the right thing to do and
partly because I hate to fight losing battles.

<snip>

Extreme conservatism is also counterproductive for the OPs

Those who read what I write a little more objectively will actually realise
that I'm not actually an extreme conservative.

<snip>

>I'll make you a deal. If you will personally undertake to post
corrections to all the mistakes Jacob Navia makes in this group, I'll
never so much as mention his name again. Fair?

Fair. I will just not be as quick to jump on my keyboard as you are,
time not permitting.

Okay, for as long as you continue to correct every single error he makes in
comp.lang.c, within a reasonable time - say, within three days of his
posting the erroneous material - I'll refrain from replying to him,
mentioning his name, or making any comment about him or his code in
comp.lang.c. But I don't think you realise the magnitude of what you've
just undertaken to do.

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

[Richard Heathfield]

Charlie Gordon said:

"Richard Heathfield" <rj*@see.sig.invalida écrit dans le message de
news: ra******************************@bt.com...

<snip>

>I'll make you a deal. If you will personally undertake to post
corrections to all the mistakes Jacob Navia makes in this group, I'll
never so much as mention his name again. Fair?

Fair.

Charlie, I see a LOT of his mistakes still uncorrected by anyone, four days
after you promised to post corrections to all his mistakes. If you can't
keep to your end of the bargain, I will not feel bound by mine.

I will just not be as quick to jump on my keyboard as you are,
time not permitting.

If you don't have much time available, you cannot possibly honour a promise
to correct all the mistakes he makes here. (Nor could I, but then I've
never made such a promise.)

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