Loading ...
Sorry, an error occurred while loading the content.

vim60ao dosinst.c OLE VC4.0 tested

Expand Messages
  • Walter Briscoe
    am looking at porting OleVim/*.bas to c. I aim to do so in VC4.0 to minimise the use of hard technology. I looked at dosinst.c for its use of
    Message 1 of 8 , Jul 27, 2001
    • 0 Attachment
      I am looking at porting OleVim/*.bas to c. I aim to do so in VC4.0 to
      minimise the use of hard technology. I looked at dosinst.c for its use
      of CoCreateInstance(). There was a comment that it had not been tested
      for VC < 5. It is now tested with VC4.0. I put the data acquisition in
      interactive operation into a function to simplify stepping through the
      program in the debugger. A recent code change puts rewind(stdin) after
      each scanf call. I found that rewind call did nothing in VC4.0.
      e.g. In program, type 6\n7\n; debugger sees both 6 and 7.
    • Bram Moolenaar
      ... Ehm, does this patch do anything besides moving things around? I don t see anything changed around the rewind(stdin). -- hundred-and-one symptoms of being
      Message 2 of 8 , Jul 27, 2001
      • 0 Attachment
        Walter Briscoe wrote:

        > I am looking at porting OleVim/*.bas to c. I aim to do so in VC4.0 to
        > minimise the use of hard technology. I looked at dosinst.c for its use
        > of CoCreateInstance(). There was a comment that it had not been tested
        > for VC < 5. It is now tested with VC4.0. I put the data acquisition in
        > interactive operation into a function to simplify stepping through the
        > program in the debugger. A recent code change puts rewind(stdin) after
        > each scanf call. I found that rewind call did nothing in VC4.0.
        > e.g. In program, type 6\n7\n; debugger sees both 6 and 7.

        Ehm, does this patch do anything besides moving things around? I don't see
        anything changed around the rewind(stdin).

        --
        hundred-and-one symptoms of being an internet addict:
        21. Your dog has its own home page.

        /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
        ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
        \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
      • Walter Briscoe
        In article of Fri, 27 Jul 2001 20:40:05 in !vim-dev, Bram Moolenaar writes ... In a sense yes;
        Message 3 of 8 , Jul 30, 2001
        • 0 Attachment
          In article <200107271840.f6RIe5E08883@...> of Fri, 27 Jul 2001
          20:40:05 in !vim-dev, Bram Moolenaar <Bram@...> writes
          >
          >Walter Briscoe wrote:
          >
          >> I am looking at porting OleVim/*.bas to c. I aim to do so in VC4.0 to
          >> minimise the use of hard technology. I looked at dosinst.c for its use
          >> of CoCreateInstance(). There was a comment that it had not been tested
          >> for VC < 5. It is now tested with VC4.0. I put the data acquisition in
          >> interactive operation into a function to simplify stepping through the
          >> program in the debugger. A recent code change puts rewind(stdin) after
          >> each scanf call. I found that rewind call did nothing in VC4.0.
          >> e.g. In program, type 6\n7\n; debugger sees both 6 and 7.
          >
          >Ehm, does this patch do anything besides moving things around? I don't see
          >anything changed around the rewind(stdin).
          >
          In a sense yes; in another sense no. The comment that says the code has
          not been tested in VC < 5 has gone as it now has. Because the data
          acquisition is now done in a function, it is easier to step through the
          code in the debugger. I did not change the rewinds of stdin as the
          technique is so alien to me. I am not qualified to say it is wrong. I
          see it as making no sense unless stdin is connected to a file; I see it
          as making no sense in that context in dosinst.c. If I flag it to Bram -
          I believe he introduced it - he can comment.
          --
          Walter Briscoe
        • Bram Moolenaar
          ... Next time I would prefer hearing the suggestion to move the code to a function. Now I had to check the code line by line to check if you changed anything.
          Message 4 of 8 , Jul 30, 2001
          • 0 Attachment
            Walter Briscoe wrote:

            > In a sense yes; in another sense no. The comment that says the code has
            > not been tested in VC < 5 has gone as it now has. Because the data
            > acquisition is now done in a function, it is easier to step through the
            > code in the debugger.

            Next time I would prefer hearing the suggestion to move the code to a
            function. Now I had to check the code line by line to check if you changed
            anything.

            > I did not change the rewinds of stdin as the
            > technique is so alien to me. I am not qualified to say it is wrong. I
            > see it as making no sense unless stdin is connected to a file; I see it
            > as making no sense in that context in dosinst.c. If I flag it to Bram -
            > I believe he introduced it - he can comment.

            I didn't introduce it, but I understand how it works. The buffered input
            stores a line of text the user typed. When you use rewind(stdin) the buffered
            text is discarded. It appears to work everywhere, but I am not 100% sure
            about it. The alternative is to use scanf(), which is a bit tricky as well.
            There are many implementations of scanf() that differ in the details, esp.
            what is skipped when using " %c".

            --
            hundred-and-one symptoms of being an internet addict:
            39. You move into a new house and decide to Netscape before you landscape.

            /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
            ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
            \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
          • Walter Briscoe
            In article of Mon, 30 Jul 2001 14:55:16 in !vim-dev, Bram Moolenaar writes ... I am sorry I did
            Message 5 of 8 , Jul 30, 2001
            • 0 Attachment
              In article <200107301255.f6UCtGr01675@...> of Mon, 30 Jul 2001
              14:55:16 in !vim-dev, Bram Moolenaar <Bram@...> writes
              >
              >Walter Briscoe wrote:
              >
              >> In a sense yes; in another sense no. The comment that says the code has
              >> not been tested in VC < 5 has gone as it now has. Because the data
              >> acquisition is now done in a function, it is easier to step through the
              >> code in the debugger.
              >
              >Next time I would prefer hearing the suggestion to move the code to a
              I am sorry I did not discuss this before doing it.

              In article <bZFLxPA9WYY7EwWU@...> of Fri, 27 Jul 2001
              16:16:13 in !vim-dev, Walter Briscoe <wbriscoe@...> writes
              >I am looking at porting OleVim/*.bas to c. I aim to do so in VC4.0 to
              >minimise the use of hard technology. I looked at dosinst.c for its use
              >of CoCreateInstance(). There was a comment that it had not been tested
              >for VC < 5. It is now tested with VC4.0. I put the data acquisition in
              >interactive operation into a function to simplify stepping through the
              >program in the debugger. A recent code change puts rewind(stdin) after
              I thought the previous sentence covered it adequately.

              >each scanf call. I found that rewind call did nothing in VC4.0.
              >e.g. In program, type 6\n7\n; debugger sees both 6 and 7.

              >function. Now I had to check the code line by line to check if you changed
              >anything.
              What is your conclusion?

              >
              >> I did not change the rewinds of stdin as the
              >> technique is so alien to me. I am not qualified to say it is wrong. I
              >> see it as making no sense unless stdin is connected to a file; I see it
              >> as making no sense in that context in dosinst.c. If I flag it to Bram -
              >> I believe he introduced it - he can comment.
              >
              >I didn't introduce it, but I understand how it works. The buffered input
              >stores a line of text the user typed. When you use rewind(stdin) the buffered
              >text is discarded. It appears to work everywhere, but I am not 100% sure
              >about it. The alternative is to use scanf(), which is a bit tricky as well.
              >There are many implementations of scanf() that differ in the details, esp.
              >what is skipped when using " %c".
              >
              I would suggest it is better to use fgets and sscanf at the cost of an
              extra buffer. The technique is unambiguous and only relies on behavior
              in the standard. I now understand what is intended by rewind(stdin) and
              scanf. I am not convinced it is required to work as intended.

              I apologise for dropping into the third person when you were in the
              second. I had intended to revise that before transmission.
              --
              Walter Briscoe
            • Bram Moolenaar
              ... As I said: nothing changed. ... I m convinced that how scanf() works is not always as it s documented, and it s sometimes even documented differently. I
              Message 6 of 8 , Jul 30, 2001
              • 0 Attachment
                Walter Briscoe wrote:

                > >function. Now I had to check the code line by line to check if you changed
                > >anything.
                > What is your conclusion?

                As I said: nothing changed.

                > I would suggest it is better to use fgets and sscanf at the cost of an
                > extra buffer. The technique is unambiguous and only relies on behavior
                > in the standard. I now understand what is intended by rewind(stdin) and
                > scanf. I am not convinced it is required to work as intended.

                I'm convinced that how scanf() works is not always as it's documented, and
                it's sometimes even documented differently. I remember having to experiment
                quite a bit before it worked properly. I think the current rewind() works
                fine, and considering how buffered I/O works I would expect it to work
                properly everwhere (it resets a pointer to the start of the buffer).

                --
                hundred-and-one symptoms of being an internet addict:
                53. To find out what time it is, you send yourself an e-mail and check the
                "Date:" field.

                /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
                \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
              • Walter Briscoe
                In article of Mon, 30 Jul 2001 20:54:29 in !vim-dev, Bram Moolenaar writes ... Do you think you
                Message 7 of 8 , Aug 1 8:09 AM
                • 0 Attachment
                  In article <200107301854.f6UIsTX06900@...> of Mon, 30 Jul 2001
                  20:54:29 in !vim-dev, Bram Moolenaar <Bram@...> writes
                  >
                  >Walter Briscoe wrote:
                  >
                  >> >function. Now I had to check the code line by line to check if you changed
                  >> >anything.
                  >> What is your conclusion?
                  >
                  >As I said: nothing changed.
                  Do you think you could change it in a manner similar to what I posted?
                  Or will you take a patch relative to the 6.0ap code?
                  It is a pain to step through the current code. I have done it often
                  enough to want to make it easier. I know I can set a breakpoint; I know
                  I can "run to here"; I usually prefer not to.

                  >
                  >> I would suggest it is better to use fgets and sscanf at the cost of an
                  >> extra buffer. The technique is unambiguous and only relies on behavior
                  >> in the standard. I now understand what is intended by rewind(stdin) and
                  >> scanf. I am not convinced it is required to work as intended.
                  >
                  >I'm convinced that how scanf() works is not always as it's documented, and
                  >it's sometimes even documented differently. I remember having to experiment
                  >quite a bit before it worked properly. I think the current rewind() works
                  >fine, and considering how buffered I/O works I would expect it to work
                  >properly everwhere (it resets a pointer to the start of the buffer).
                  >
                  I read and hear from those who know more about C than I ever will that
                  scanf() is one stage better than gets(). I don't understand why you use
                  it. I don't understand why you accept the confusion and doubt that
                  rewind(stdin) introduces. I now understand what it is intended to do. I
                  still dislike it. I think we will have to agree to differ on this.
                  --
                  Walter Briscoe
                • Bram Moolenaar
                  ... I actually don t see the advantage. The loop that awaits a choice probably doesn t have to be debugged, it is unchanged for quite a while. If you want to
                  Message 8 of 8 , Aug 1 10:50 AM
                  • 0 Attachment
                    Walter Briscoe wrote:

                    > Do you think you could change it in a manner similar to what I posted?
                    > Or will you take a patch relative to the 6.0ap code?
                    > It is a pain to step through the current code. I have done it often
                    > enough to want to make it easier. I know I can set a breakpoint; I know
                    > I can "run to here"; I usually prefer not to.

                    I actually don't see the advantage. The loop that awaits a choice probably
                    doesn't have to be debugged, it is unchanged for quite a while. If you want
                    to debug installing, but a breakpoint at the install() function.
                    I like to see the main thread of what happens in one place.

                    > I read and hear from those who know more about C than I ever will that
                    > scanf() is one stage better than gets(). I don't understand why you use
                    > it.

                    Ehm, there is no call to gets()...

                    > I don't understand why you accept the confusion and doubt that
                    > rewind(stdin) introduces. I now understand what it is intended to do. I
                    > still dislike it. I think we will have to agree to differ on this.

                    I have enough experience with scanf() to have confusion and doubt about
                    that... Especially when using a space in the string. For example, does it
                    skip characters above 128? A function key produces that. Does %c return a CR
                    or LF or both?

                    [just discovered I missed the first two episodes of the Hitchhikers Guide to
                    the Galaxy repeat on BBC2 :-(]

                    --
                    From "know your smileys":
                    <|-) Chinese
                    <|-( Chinese and doesn't like these kind of jokes

                    /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                    ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
                    \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                  Your message has been successfully submitted and would be delivered to recipients shortly.