«

On Dec 24, 10:09 pm, santosh <santosh....@gmail.com> wrote:
> [...] I understand that the Committee had an overall policy to
> include only those new functions in the Standard library that would
> be impossible or difficult to replicate in user code.

Excuse me, what? You mean like the SafeStr library that Microsoft
tricked the committee into adopting? Every function in there is
trivial, with basically no opportunity for compiler implementation
improvements.

Its obvious that the C standards committee are also trying to set a
direction for the language irrespective of the difficulty of the
functions they add. (They also don't have any idea what they are
doing, but that's a different story.)

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

On Dec 25, 9:51 pm, CBFalconer <cbfalco...@yahoo.com> wrote:
> jacob navia wrote:
> > Flash Gordon wrote:
>
> ... snip ...
>
> >> Since you have opened the file in binary mode and MacOS 9.x and
> >> earlier use '\r' as the line terminator you have just converted
> >> the file to one long line on some systems.> >
>
> > Yes, will not work in DS9000 and MAC os9.x Easy to change though.
> > There is no portable way to know what line separator the system
> > uses.
>
> Yes there is. Just open the file in text mode (i.e. without the
> "rb") and wait until you detect a '\n' in the stream. That is
> exactly where a line separator occured.
That's a where, not a what.

CBFalconer wrote:
> jacob navia wrote:
>> Flash Gordon wrote:
>>
> ... snip ...
>>> Since you have opened the file in binary mode and MacOS 9.x and
>>> earlier use '\r' as the line terminator you have just converted
>>> the file to one long line on some systems.> >
>> Yes, will not work in DS9000 and MAC os9.x Easy to change though.
>> There is no portable way to know what line separator the system
>> uses.
>
> Yes there is. Just open the file in text mode (i.e. without the
> "rb") and wait until you detect a '\n' in the stream. That is
> exactly where a line separator occured.
>
Not here. Opening a text file with CR line terminations in "r" mode is
fine but the CR bytes (0x0d) are never seen. I get one long line.

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

On Dec 26, 12:56 am, Joe Wright <joewwri...@comcast.net> wrote:
> CBFalconer wrote:
> > jacob navia wrote:
> >> Flash Gordon wrote:
>
> > ... snip ...
> >>> Since you have opened the file in binary mode and MacOS 9.x and
> >>> earlier use '\r' as the line terminator you have just converted
> >>> the file to one long line on some systems.> >
> >> Yes, will not work in DS9000 and MAC os9.x Easy to change though.
> >> There is no portable way to know what line separator the system
> >> uses.
>
> > Yes there is. Just open the file in text mode (i.e. without the
> > "rb") and wait until you detect a '\n' in the stream. That is
> > exactly where a line separator occured.
>
> Not here. Opening a text file with CR line terminations in "r" mode is
> fine but the CR bytes (0x0d) are never seen. I get one long line.
He is not talking about CR (which is ascii) or 0x0D which is just a
value, but '\n'.

jacob navia wrote, On 25/12/07 11:00:
> Flash Gordon wrote:
>> Wouldn't it be more sensible to use the mode the user passes in?
>
> No, because in text mode the standard doesn't guarantee that ftell and
> fseek will work correctly!

You have it wrong. The standard guarantees that in text mode they will
work correctly on any conforming implementation, it's just that the
value returned by ftell does not have to be a byte count. In binary
mode, on the other hand, an fseek SEEK_END does not have to be
meaningfully supported. I suggest you go back and read questions 12.40
and 19.12 of the comp.lang.c FAQ or read the descriptions of the
functions in the standard.

<snip>

>> Also you fail to allow for it reading fewer then the number of 1 byte
>> members you specify. This can happen for a number of reasons.

Ignoring this problem?

>>> goto ioerror;
>>> result[l] = 0;
>>> fclose(f);
>>> if (strchr(mode,'b') == NULL) {
>>> char *src = result,*dst = result;
>>> while ((src - result) < l) {
>>
>> Hmm. You have an initialisation, a test, and an increment, wouldn't a
>> for loop have been more natural?
>>
>>> if (*src != '\r')
>>> *dst++ = *src;
>>> src++;
>>
>> Since you have opened the file in binary mode and MacOS 9.x and
>> earlier use '\r' as the line terminator you have just converted the
>> file to one long line on some systems.
>
> Yes, will not work in DS9000 and MAC os9.x

Or under VMS.

> Easy to change though.

Each time you say that I'm sure that someone can come up with another
example where you will have to change it.

> There is no portable way to know what line separator the system uses.

That is part of the reason for having text mode, so that you the
programmer do not have to worry about how lines are indicated.

Oh, and under Windows opening in binary mode means you will not
correctly handle ^Z terminated text files so by trying to do it yourself
instead of letting the library handle it you have got it wrong for
Windows as well.

Your function will also have problems if someone tries to use it on stdin.
--
Flash Gordon

wrote:
> On Dec 26, 12:56 am, Joe Wright <joewwri...@comcast.net> wrote:
>> CBFalconer wrote:
>>> jacob navia wrote:
>>>> Flash Gordon wrote:
>>> ... snip ...
>>>>> Since you have opened the file in binary mode and MacOS 9.x and
>>>>> earlier use '\r' as the line terminator you have just converted
>>>>> the file to one long line on some systems.> >
>>>> Yes, will not work in DS9000 and MAC os9.x Easy to change though.
>>>> There is no portable way to know what line separator the system
>>>> uses.
>>> Yes there is. Just open the file in text mode (i.e. without the
>>> "rb") and wait until you detect a '\n' in the stream. That is
>>> exactly where a line separator occured.
>> Not here. Opening a text file with CR line terminations in "r" mode is
>> fine but the CR bytes (0x0d) are never seen. I get one long line.
> He is not talking about CR (which is ascii) or 0x0D which is just a
> value, but '\n'.

Ok vippstar whoever you are. You weren't listening. Among the three
systems, Apple, PC and Unix there are three line endings. Apple used a
single CR, Unix a single LF and the PC two bytes, CRLF.

Jacob said "There is no portable way to know what line separator the
system uses". Chuck said "Just open the file in text mode (i.e. without
the "rb") and wait until you detect a '\n' in the stream".

My response to Chuck was that Hell will freeze over before a single CR
in a text stream will be converted to LF for me to see (on my system here).

Do all of us the favor of assuming we know LF is '\n' and CR is '\r'.
Now that you understand my reply to Chuck, please feel free to comment
on it.

Before you attempt to correct me again, "CR is ascii but 0x0d is just a
value" won't fly. You'll have to do better.

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

jacob navia wrote:
> CBFalconer wrote:
>> jacob navia wrote:
>>
.... snip ...
>>> There is no portable way to know what line separator the system
>>> uses. ^^^^^^^^^^^^^^^
>>
>> Yes there is. Just open the file in text mode (i.e. without the
>> "rb") and wait until you detect a '\n' in the stream. That is
>> exactly where a line separator occured.
>
> So What? You think the function should discover each time it is
> called the line separator?

My reply simply denied your erroneous underlined statement above.

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com

Joe Wright wrote:
> CBFalconer wrote:
>> jacob navia wrote:
>>> Flash Gordon wrote:
>>>
>> ... snip ...
>>>> Since you have opened the file in binary mode and MacOS 9.x and
>>>> earlier use '\r' as the line terminator you have just converted
>>>> the file to one long line on some systems.
>>>
>>> Yes, will not work in DS9000 and MAC os9.x Easy to change though.
>>> There is no portable way to know what line separator the system
>>> uses.
>>
>> Yes there is. Just open the file in text mode (i.e. without the
>> "rb") and wait until you detect a '\n' in the stream. That is
>> exactly where a line separator occured.
>
> Not here. Opening a text file with CR line terminations in "r" mode
> is fine but the CR bytes (0x0d) are never seen. I get one long line.

Then (surprise) '\r' is not used as a line termination. Your file
contains one long line. Notice that I never mentioned '\r' above,
but I did mention '\n'. So does the C standard.

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>


--
Posted via a free Usenet account from http://www.teranews.com

On Dec 26, 4:19 am, Joe Wright <joewwri...@comcast.net> wrote:
> vipps...@gmail.com wrote:
> > On Dec 26, 12:56 am, Joe Wright <joewwri...@comcast.net> wrote:
> >> CBFalconer wrote:
> >>> jacob navia wrote:
> >>>> Flash Gordon wrote:
> >>> ... snip ...
> >>>>> Since you have opened the file in binary mode and MacOS 9.x and
> >>>>> earlier use '\r' as the line terminator you have just converted
> >>>>> the file to one long line on some systems.> >
> >>>> Yes, will not work in DS9000 and MAC os9.x Easy to change though.
> >>>> There is no portable way to know what line separator the system
> >>>> uses.
> >>> Yes there is. Just open the file in text mode (i.e. without the
> >>> "rb") and wait until you detect a '\n' in the stream. That is
> >>> exactly where a line separator occured.
> >> Not here. Opening a text file with CR line terminations in "r" mode is
> >> fine but the CR bytes (0x0d) are never seen. I get one long line.
> > He is not talking about CR (which is ascii) or 0x0D which is just a
> > value, but '\n'.
>
> Ok vippstar whoever you are. You weren't listening. Among the three
> systems, Apple, PC and Unix there are three line endings. Apple used a
> single CR, Unix a single LF and the PC two bytes, CRLF.
You are not listening.
What three systems? There are no systems in C.
> Do all of us the favor of assuming we know LF is '\n' and CR is '\r'.
> Now that you understand my reply to Chuck, please feel free to comment
> on it.
I understood it before as well, and I don't feel like reposting my
comment.
> Before you attempt to correct me again, "CR is ascii but 0x0d is just a
> value" won't fly. You'll have to do better.
With all the respect, I have a feeling that nothing will do.

Joe Wright <> writes:
[...]
> Ok vippstar whoever you are. You weren't listening. Among the three
> systems, Apple, PC and Unix there are three line endings. Apple used a
> single CR, Unix a single LF and the PC two bytes, CRLF.
>
> Jacob said "There is no portable way to know what line separator the
> system uses". Chuck said "Just open the file in text mode
> (i.e. without the "rb") and wait until you detect a '\n' in the
> stream".
>
> My response to Chuck was that Hell will freeze over before a single CR
> in a text stream will be converted to LF for me to see (on my system
> here).

Agreed, what Chuck suggested will not reliably detect what line
terminator a system uses. You might never see a '\n' when reading a
text file in binary mode (if the system doesn't use '\n' as its line
terminator, or as part of it).

If you write a small file in text mode, then read the same file in
binary mode, then you *might* be able to determine how the system
represents line endings. At least it should work for Unix (LF), MacOS
<= 9 (CR), and DOS/Windows (CRLF). But there are stranger systems
than any of those out there, for example, some that don't use a
character sequence to terminate a line.

But the point is (or should be) that most of the time *it doesn't
matter* how the system represents line endings. If you want to read a
text file, use text mode and let the implementation take care of it
for you. If you want to read a "foreign" text file, you need to know
how it's represented; you might be able to get away with guessing, but
it's better to know by other means. (How do you tell the difference
between a Windows text file and a Unix text file where each line
happens to end with a carriage-return?)

> Do all of us the favor of assuming we know LF is '\n' and CR is
> \r'. Now that you understand my reply to Chuck, please feel free to
> comment on it.

LF isn't *necessarily* '\n'. '\n', or new-line, is a character that
the C implementation uses internally to represent a line terminator.
Whatever representation the OS uses is translated to '\n' on text-mode
input. On old MacOS, for example, it would have been sensible for
'\n' to be the ASCII CR character; I don't know whether it was
actually done that way.

It may be the case that every non-EBCDIC uses the ASCII LF character
for '\n', but the standard doesn't guarantee this.

[...]

--
Keith Thompson (The_Other_Keith) <kst->
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"