Thread: pointer problem

Originally Posted by Dave_Sinkula

Yes, I just don't think you read it right.

What am I reading incorrectly?

In http://msdn.microsoft.com/library/de...c_._wfopen.asp
the paragraph following "Open in text ... " says

Also, in text mode, carriage return–linefeed combinations are translated into single linefeeds on input...

and a few lines below that

If t or b is not given in mode, the default translation mode is defined by the global variable _fmode.

and the _fmode page says that the default setting of _fmode is _O_TEXT.

(I take that to be the explanation why my original code worked in MSVC even though I used "r", not "t" in fopen(), the input file had CR/LF on each line AND I had nothing in my original code to handle the CRs. If I'm reading it wrong, then why did my code work in MSVC but not in linux/gcc?)

OK. Thanks for pointing that out.

Anyhow, (if I'm now reading correctly) "r" by itself indicates text mode in both the 89 and 99 standards, and Microsoft's default also interprets "r" as "open a text file for reading", so no problem there. The difference is that for Microsoft, text mode includes the translation of the CR/LF combination into a single LF -- this translation is not part of either standard. My point was just that this explains why my original code worked in MSVC and not in Linux. Do you disagree with that?

Originally Posted by Dave_Sinkula

The translation is part of both standards. What your code does depends on which platform the code was compiled. And in which way the file was generated.

???
I don't see any mention in c99 about translating <13><10> to <10> while reading.
The input file was written in Notepad, so it had <13><10>at the end of each line. The exact same file was used in the linux machine.
And this code

Code:

	for(i=0; (i<9) && ((ch = fgetc(infile)) != EOF) && (ch != '\n'); i++)
		inbuffer[i] = ch;
	inbuffer[i] = '\0';

in Windows produced strings that contained no <13> characters. The same code in Linux generated strings each of which ended with <13>.

No.

You aren't understanding what I'm saying.

I wrote the file in Notepad, so, yes, the file has \r \n on each line because that's the way it's done in Windows. I figured that out yesterday.

And I'm not "blaming" linux. If anything, I'm blaming myself for not writing my code to handle the \r's in the first place.

I was simply trying to be sure that I understand why, on the Windows machine, my original code worked the way I intended despite my mistake.

Characters may have to be added, altered, or deleted on input and output to conform to differing conventions for representing text in the host environment. Thus, there need not be a one-to-one correspondence between the characters in a stream and those in the external representation.

Unfortunately, they didn't say "may be" or "have to be" but instead, "may have to be". I think that means that the decision of whether or not to add or delete characters is left to the implementor. Or is there a convention that ALL Windows C-implementations will automatically remove the \r characters when reading in text mode? Are you saying that every implementation of C intended for the Windows environment is obligated by that standard to remove the \r characters?

(I just tried my original "dumb" code using the Borland bcc32 compiler, and it worked fine.)

This is like trying to get a straight answer from the Delphic Sybil.

The Wikipedia article was interesting & informative and I thank you for shoving my face in it. However, is it authoritative?

I still don't see where either the 89 or 99 standard mandates:

(from http://en.wikipedia.org/wiki/Newline)

The[/url] C standard only guarantees two things:

...

2. When writing a file in text mode, '\n' is transparently translated to the native newline sequence used by the system, which may be longer than one character. When reading in text mode, the native newline sequence is translated back to '\n'. In binary mode, the second mode of I/O supported by the C library, no translation is performed, and the internal representation of any escape sequence is output directly.

Still, that seems to be the behavior of both the Microsoft and the Borland compilers. Reading in text mode (in Windows), character 13 is completely invisible; reading the same file in binary mode and character 13 is definitely there, on every line.

Does every Windows C compiler adhere to that behavior?