pointer problem

This is a discussion on pointer problem within the C Programming forums, part of the General Programming Boards category; 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 ...

  1. #16
    Registered User
    Join Date
    Feb 2003
    Posts
    595
    Quote 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?)

  2. #17
    Just Lurking Dave_Sinkula's Avatar
    Join Date
    Oct 2002
    Posts
    5,006
    Quote Originally Posted by R.Stiltskin
    What am I reading incorrectly?
    The part where you consider "t" a mode, rather than "rt". As in,
    In addition to the above values, the following characters can be included in mode to specify the translation mode for newline characters
    Please also follow the links to C89 and C99 parameters for fopen.
    7. It is easier to write an incorrect program than understand a correct one.
    40. There are two ways to write error-free programs; only the third one works.*

  3. #18
    Registered User
    Join Date
    Feb 2003
    Posts
    595
    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?

  4. #19
    Just Lurking Dave_Sinkula's Avatar
    Join Date
    Oct 2002
    Posts
    5,006
    Quote Originally Posted by R.Stiltskin
    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?
    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.
    7. It is easier to write an incorrect program than understand a correct one.
    40. There are two ways to write error-free programs; only the third one works.*

  5. #20
    Registered User
    Join Date
    Feb 2003
    Posts
    595
    Quote 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>.

  6. #21
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    No. The Windows machine is adding the \r. Linux doesn't use \r. It only uses \n. Make a file in windows, write newlines to it. ( puts( "\n" ) ) Open the file in Linux, read it a byte at a time. Be amazed at discovering a \r in the file. Blame it on Linux, when it's really Windows that is adding them.

    You aren't understanding what you're reading.


    Quzah.
    Hope is the first step on the road to disappointment.

  7. #22
    Registered User
    Join Date
    Feb 2003
    Posts
    595
    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.

  8. #23
    Just Lurking Dave_Sinkula's Avatar
    Join Date
    Oct 2002
    Posts
    5,006
    Quote Originally Posted by R.Stiltskin
    ???
    I don't see any mention in c99 about translating <13><10> to <10> while reading.
    The fopen links describe which mode is selected. To understand the meaning of the modes, scroll back a bit.
    #2

    A text stream is an ordered sequence of characters composed into lines, each line consisting of zero or more characters plus a terminating new-line character. Whether the last line requires a terminating new-line character is implementation-defined. 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. Data read in from a text stream will necessarily compare equal to the data that were

    earlier written out to that stream only if: the data consist only of printing characters and the control characters horizontal tab and new-line; no new-line character is immediately preceded by space characters; and the last character is a new-line character. Whether space characters that are written out immediately before a new-line character appear when read in is implementation-defined.
    7. It is easier to write an incorrect program than understand a correct one.
    40. There are two ways to write error-free programs; only the third one works.*

  9. #24
    Registered User
    Join Date
    Feb 2003
    Posts
    595
    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.)

  10. #25
    Just Lurking Dave_Sinkula's Avatar
    Join Date
    Oct 2002
    Posts
    5,006
    Let's revisit this article. Notice the different text mode representations per platform. Depending on which platform you target, the expected translation will be performed. So the same code can mean different things happen on different platforms when using text mode.
    7. It is easier to write an incorrect program than understand a correct one.
    40. There are two ways to write error-free programs; only the third one works.*

  11. #26
    Registered User
    Join Date
    Feb 2003
    Posts
    595
    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?

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. pointer to pointer realloc problem
    By prakash0104 in forum C Programming
    Replies: 14
    Last Post: 04-06-2009, 08:53 PM
  2. Another pointer problem
    By mikahell in forum C++ Programming
    Replies: 21
    Last Post: 07-20-2006, 07:37 PM
  3. Pointer problem
    By mikahell in forum C++ Programming
    Replies: 5
    Last Post: 07-20-2006, 10:21 AM
  4. Quick question about SIGSEGV
    By Cikotic in forum C Programming
    Replies: 30
    Last Post: 07-01-2004, 07:48 PM
  5. pointer problem
    By DMaxJ in forum C Programming
    Replies: 4
    Last Post: 06-11-2003, 12:14 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21