zsh-workers
 help / color / mirror / code / Atom feed
* "read" broken in 2.6-beta21?
@ 1996-06-27  0:11 Colm Buckley
  1996-06-27 21:42 ` Zoltan Hidvegi
  0 siblings, 1 reply; 2+ messages in thread
From: Colm Buckley @ 1996-06-27  0:11 UTC (permalink / raw)
  To: zsh-workers


This has been affecting me recently; I just tracked it down to the
following:

The "read" command in zsh2.6-beta21 behaves strangely when the input
exceeds 63 characters; the remaining characters in the line are
truncated.  For example :

$ read x
1234567890123456789012345678901234567890123456789012345678901234567890
$ echo $x
123456789012345678901234567890123456789012345678901234567890123
$

I don't *think* this affected previous versions of zsh.  If a static
buffer is being used for "read", might I suggest that it be increased in
size to something greater than 64 bytes?

(Apologies if this has been pointed out already; I don't subscribe to
zsh-workers any more so I'm not up to speed on the current discussion.
Please e-mail me with comments.)

           Colm

-- 
Colm Buckley B.F. | EMail : Colm.Buckley@tcd.ie or colm@lspace.org
Computer Science  | WWW   : http://isg.cs.tcd.ie/cbuckley/
Trinity College   | Phone : +353 87 469146 (087-469146 within Ireland)
Dublin 2, Ireland | "Microsoft : Where do you want to crash today?"



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: "read" broken in 2.6-beta21?
  1996-06-27  0:11 "read" broken in 2.6-beta21? Colm Buckley
@ 1996-06-27 21:42 ` Zoltan Hidvegi
  0 siblings, 0 replies; 2+ messages in thread
From: Zoltan Hidvegi @ 1996-06-27 21:42 UTC (permalink / raw)
  To: Colm Buckley; +Cc: Zsh hacking and development

> 
> This has been affecting me recently; I just tracked it down to the
> following:
> 
> The "read" command in zsh2.6-beta21 behaves strangely when the input
> exceeds 63 characters; the remaining characters in the line are
> truncated.  For example :
> 
> $ read x
> 1234567890123456789012345678901234567890123456789012345678901234567890
> $ echo $x
> 123456789012345678901234567890123456789012345678901234567890123
> $
> 
> I don't *think* this affected previous versions of zsh.  If a static
> buffer is being used for "read", might I suggest that it be increased in
> size to something greater than 64 bytes?

Yes, this bug appeared in beta21 but not because of static buffers.  The
patch below should fix that.

Zoltan


*** Src/builtin.c	1996/06/26 22:32:07	2.47
--- Src/builtin.c	1996/06/27 21:25:38
***************
*** 4976,4983 ****
  		*bptr++ = c;
  	    /* increase the buffer size, if necessary */
  	    if (bptr >= buf + bsiz - 1) {
  		buf = realloc(buf, bsiz *= 2);
! 		bptr = buf + (bsiz / 2);
  	    }
  	}
  	/* handle EOF */
--- 4976,4985 ----
  		*bptr++ = c;
  	    /* increase the buffer size, if necessary */
  	    if (bptr >= buf + bsiz - 1) {
+ 		int blen = bptr - buf;
+ 
  		buf = realloc(buf, bsiz *= 2);
! 		bptr = buf + blen;
  	    }
  	}
  	/* handle EOF */
***************
*** 5055,5062 ****
  		*bptr++ = c;
  	    /* increase the buffer size, if necessary */
  	    if (bptr >= buf + bsiz - 1) {
  		buf = realloc(buf, bsiz *= 2);
! 		bptr = buf + (bsiz / 2);
  	    }
  	}
      while (bptr > buf && iwsep(bptr[-1]))
--- 5057,5066 ----
  		*bptr++ = c;
  	    /* increase the buffer size, if necessary */
  	    if (bptr >= buf + bsiz - 1) {
+ 		int blen = bptr - buf;
+ 
  		buf = realloc(buf, bsiz *= 2);
! 		bptr = buf + blen;
  	    }
  	}
      while (bptr > buf && iwsep(bptr[-1]))



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~1996-06-27 23:19 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1996-06-27  0:11 "read" broken in 2.6-beta21? Colm Buckley
1996-06-27 21:42 ` Zoltan Hidvegi

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).