Re: Is there really any interest in a patch to allow cvs 1.11.6 torun on HP/COMPAQ/TANDEM/NSK or am I just wasting my time.....

[Paul Edwards]

"Kelly F. Hickel" <kfh@mqsoftware.com> wrote in message 
news:mailman.784.1064610662.21628.bug-cvs@gnu.org...
> Here's an example of one such change (most are limited to client.c),
> there might be a cleaner way to do it.  In fact, the comment at the top
> of the area indicates that at least one person thought that it would be
> good to go in this direction anyway.  If there were a consensus of "the
> right way" to do this, I'd be interesting in at least helping implement
> that, even if it meant more work for me.

> I realize more people are interested in the dev version, but I really

I don't know how you know that.

> need to be using a stable version.   I can whack the changes into my
> copy of the stable and help on the dev changes, but I'd *REALLY* want to
> know that the changes were going to be accepted before I went to that
> extra length.

Personally, I think that this should be considered to be a fix to a
bug that is preventing CVS from working on Tandem etc, and
should go into the stable release.  And FYI, about 3 months ago
I was talking to someone, who was considering going to work
for a company running Tandem NSK to do source control, and
I told him to install CVS there, and that if he didn't want the
job, I'd take it.  He didn't take the job, and I may contact the
company in January to see if the position is still available.  So
can you have it ready by then?


***************
*** 4912,4922 ****
         Instead of this we should just be reading a block of
         data (e.g. 8192 bytes), writing it to the network, and
         so on until EOF.  */
      while ((len = read (fd, bufp, (buf + sb.st_size) - bufp)) >
0)
          bufp += len;
!
      if (len < 0)
!         error (1, errno, "reading %s", short_pathname);

      newsize = bufp - buf;
  }
--- 4952,4974 ----
         Instead of this we should just be reading a block of
         data (e.g. 8192 bytes), writing it to the network, and
         so on until EOF.  */
+
+ #ifdef WRITE_CANT_HANDLE_LARGE_BUF
+       int to_read=(buf + sb.st_size) - bufp;
+       if(to_read > SINGLE_WRITE_SIZE)
+         to_read = SINGLE_WRITE_SIZE;
+     while ((len = read (fd, bufp, to_read)) > 0) {
+         bufp += len;
+         to_read=(buf + sb.st_size) - bufp;
+         if(to_read > SINGLE_WRITE_SIZE)
+           to_read = SINGLE_WRITE_SIZE;
+       }
+ #else
      while ((len = read (fd, bufp, (buf + sb.st_size) - bufp)) >
0)
          bufp += len;
! #endif
      if (len < 0)
!         error (1, errno, "reading #7 %s", short_pathname);

      newsize = bufp - buf;
      }

Yuck.  I think this "reading #7" is overkill.  And I would
create a function called "saferead" or something like that,
which replaces read, so that the only change you see to
client.c is read being replaced by saferead.

And then you create a saferead that has all that crap in it.
Maybe in subr.c?

And in actual fact, you can even put a #define read saferead
in a header file, so you don't need to touch client.c at all.

But note, it is not me who decides what gets accepted, so
don't do that work based on my say-so.

On the other hand, your changes above will make it easier
for you to upgrade to a new version of CVS in the future,
because your changes are purely additional code, you're
not changing other code that is subject to change.

BFN.  Paul.