[Vim-vms] RE: Having trouble building vim on vms 5.5-2... (fwd)

[Arpadffy Zoltan]

hi,

sorry for delayed answer, but vim-vms at polarfox.com does not exists any more,
just
vim-vms at polarHOME.com, because the old polarfox list did not have spam
control and could not provide required users privacy: therefore, 2 years
ago, I moved the list over to polarHOME.com 

It is true that I am guilty for that code... I am sorry for inconvenience.

However Bram's solution looks (and works) very good.
It should be used.

Regards, Z



---------- Forwarded message ----------
Date: Mon, 20 Oct 2003 13:52:29 +0200
From: Bram Moolenaar <Bram at moolenaar.net>
To: Coen Engelbarts <coen.engelbarts at cmg.nl>
Cc: vim at vim.org, vim-vms at polarfox.com
Subject: RE: Having trouble building vim on vms 5.5-2...


Coen Engelbarts wrote:

> I wanted to respond before, but I had some mail problems.
> I'd just like to point out a few things, just in case:
>
> - I don't think this is really a 'bug'. This is valid C, and compiles
> fine. However, it uses a C 99 feature, so it won't compile in 'old' ANSI
> C. I doubt that C 99 is available on OpenVMS VAX V5.5-2. (current VMS
> versions are 7.2 or so, on Alpha, soon on Itanic)
>
> - I think this is part of the I/O rewrite for Vim/VMS somewhere in 6.1.
> That removed the last bug (AFAIK) that crashed vim on VMS. That would be
> path 6.1.369. Oh, Bram noted that already. Please be careful with it. :-)
>
> - A/the good place to ask Vim/VMS questions is the vim-vms mailing list:
> vim-vms at polarfox.com. That list and the website
> http://www.polarfox.com/vim/ are maintained by Zoltan Arpadffy
> (arpadffy(at)polarfox.com), who probably wrote this code.
>
> - Yes, it probably is a good idea to remove C99 usage from vim, so it
> can be compiled on older systems.
>
>
> Finally, just out of 'academic' curiosity:
> I'm a little worried about using a malloc/memset/free here. Isn't that a
> bit much for each keystroke? Wouldn't it be better to waste a little
> memory and just use a fixed size buffer here?
> e.g replace
>              char    ibuf[nbytes];
> with
>              char    ibuf[250];
>              nbytes = 250;
> where 250 is INBUFLEN from ui.c, when client-server/etc. is not enabled.
> What do you think?
>
> Or perhaps
>              static char    ibuf[250];
>              nbytes = 250;
> I think that the buffer does not need to be initialised with zeroes, but
> I'm not sure.

A fixed-size buffer has the problem that this might fail when I decide
to use a larger buffer elsewhere in Vim, and I probably won't think of
checking that it still works for VMS.

I also don't like using malloc()/free() here, it is quite a bit of
overhead.

I think that clearing of the buffer is needed to make sure the string
ends in a NUL, so that we can use strlen().  But that also means there
must be room for a terminating NUL after the bytes that are read.

How about this approach:  Read the input directly into "inbuf", but pass
a size that is one byte less.  Like this:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
    int
vms_read(char *inbuf, size_t nbytes)
{
    int     status, function, len;
    float   wait = 0.05;
    TT_MODE tt_mode;

    /* whatever happened earlier we need an iochan here */
    if (!iochan)
       tt_mode = get_tty();

    function = (IO$_READLBLK | IO$M_NOECHO | IO$M_TIMED | IO$M_ESCAPE);
    memset(inbuf, 0, nbytes);

    while (1)
    {
	status =
sys$qiow(0,iochan,function,&iosb,0,0,inbuf,nbytes-1,0,0,0,0);
	len = strlen(inbuf);
	if (len > 0)
	    break;
	lib$wait(&wait);
    }
    return len;
}
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

The only drawback is that you can't read NUL bytes this way.  But that
has always been so.  The solution that Walter Briscoe sent could solve
that, but we must be very sure it works on all kinds of VMS.  It at
least has a header file problem.

-- 
FIRST HEAD:  Oh! quick! get the sword out I want to cut his head off.
THIRD HEAD:  Oh, cut your own head off.
SECOND HEAD: Yes - do us all a favour.
                 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES
LTD

 /// Bram Moolenaar -- Bram at Moolenaar.net -- http://www.Moolenaar.net   \\\
///          Creator of Vim - Vi IMproved -- http://www.Vim.org          \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///