9front - general discussion about 9front
 help / color / mirror / Atom feed
* [9front] sam input line length limits
@ 2021-02-13  0:45 sl
  2021-02-13  2:47 ` Nick Owens
  2021-02-13  3:43 ` ori
  0 siblings, 2 replies; 7+ messages in thread
From: sl @ 2021-02-13  0:45 UTC (permalink / raw)
  To: 9front

sam.h says:

/*
 * BLOCKSIZE is relatively small to keep memory consumption down.
 */

and:

#define BLOCKSIZE 2048

and:

#define STRSIZE (2*BLOCKSIZE)

is there a compelling reason to keep STRSIZE so small, in this day and
age?

problem case:

users trying to paste in long articles from websites.

sl

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

* Re: [9front] sam input line length limits
  2021-02-13  0:45 [9front] sam input line length limits sl
@ 2021-02-13  2:47 ` Nick Owens
  2021-02-13  3:43 ` ori
  1 sibling, 0 replies; 7+ messages in thread
From: Nick Owens @ 2021-02-13  2:47 UTC (permalink / raw)
  To: 9front

i would be fine bumping the snarf size and making this match. 640k
ought to be enough for anybody.

On Fri, Feb 12, 2021 at 4:48 PM <sl@stanleylieber.com> wrote:
>
> sam.h says:
>
> /*
>  * BLOCKSIZE is relatively small to keep memory consumption down.
>  */
>
> and:
>
> #define BLOCKSIZE 2048
>
> and:
>
> #define STRSIZE (2*BLOCKSIZE)
>
> is there a compelling reason to keep STRSIZE so small, in this day and
> age?
>
> problem case:
>
> users trying to paste in long articles from websites.
>
> sl

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

* Re: [9front] sam input line length limits
  2021-02-13  0:45 [9front] sam input line length limits sl
  2021-02-13  2:47 ` Nick Owens
@ 2021-02-13  3:43 ` ori
  2021-02-13  3:55   ` sl
  2021-02-13 16:25   ` Steve Simon
  1 sibling, 2 replies; 7+ messages in thread
From: ori @ 2021-02-13  3:43 UTC (permalink / raw)
  To: 9front

Quoth sl@stanleylieber.com:
> sam.h says:
> 
> /*
>  * BLOCKSIZE is relatively small to keep memory consumption down.
>  */
> 
> and:
> 
> #define BLOCKSIZE 2048
> 
> and:
> 
> #define STRSIZE (2*BLOCKSIZE)
> 
> is there a compelling reason to keep STRSIZE so small, in this day and
> age?
> 
> problem case:
> 
> users trying to paste in long articles from websites.
> 
> sl
> 

I'd be in favor of bumping STRSIZE up a lot.
It only seems to be used as a "sane upper
bound" on string length, so changing the one
place that uses it as a stack buffer and over
to malloc should be safe.

Here's an untested diff that bumps it to 512
megabytes.

diff -r ce98610ce572 sys/src/cmd/sam/address.c
--- a/sys/src/cmd/sam/address.c	Wed Feb 10 15:42:18 2021 -0800
+++ b/sys/src/cmd/sam/address.c	Fri Feb 12 19:41:41 2021 -0800
@@ -143,14 +143,16 @@
 int
 filematch(File *f, String *r)
 {
-	char *c, buf[STRSIZE+100];
+	char *c, *s;
 	String *t;
 
 	c = Strtoc(&f->name);
-	sprint(buf, "%c%c%c %s\n", " '"[f->mod],
+	s = smprint("%c%c%c %s\n", " '"[f->mod],
 		"-+"[f->rasp!=0], " ."[f==curfile], c);
+	if(s == nil)
+		error(Etoolong);
 	free(c);
-	t = tmpcstr(buf);
+	t = tmpcstr(s);
 	Strduplstr(&genstr, t);
 	freetmpstr(t);
 	/* A little dirty... */
@@ -159,6 +161,7 @@
 	bufreset(menu);
 	bufinsert(menu, 0, genstr.s, genstr.n);
 	compile(r);
+	free(s);
 	return execute(menu, 0, menu->nc);
 }
 
diff -r ce98610ce572 sys/src/cmd/sam/sam.h
--- a/sys/src/cmd/sam/sam.h	Wed Feb 10 15:42:18 2021 -0800
+++ b/sys/src/cmd/sam/sam.h	Fri Feb 12 19:41:41 2021 -0800
@@ -18,7 +18,7 @@
 
 #define	INFINITY	0x7FFFFFFFL
 #define	INCR		25
-#define	STRSIZE		(2*BLOCKSIZE)
+#define	STRSIZE		(512<<20)
 
 typedef long		Posn;		/* file position or address */
 typedef	ushort		Mod;		/* modification number */


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

* Re: [9front] sam input line length limits
  2021-02-13  3:43 ` ori
@ 2021-02-13  3:55   ` sl
  2021-02-13 16:25   ` Steve Simon
  1 sibling, 0 replies; 7+ messages in thread
From: sl @ 2021-02-13  3:55 UTC (permalink / raw)
  To: 9front

> Here's an untested diff that bumps it to 512
> megabytes.

thanks, testing it now.

sl

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

* Re: [9front] sam input line length limits
  2021-02-13  3:43 ` ori
  2021-02-13  3:55   ` sl
@ 2021-02-13 16:25   ` Steve Simon
  2021-02-13 20:06     ` ori
  1 sibling, 1 reply; 7+ messages in thread
From: Steve Simon @ 2021-02-13 16:25 UTC (permalink / raw)
  To: 9front

Normally I would be very wary of changing sam it has served
me well for many years, but I am with you on this one,
it has bitten me in the past and its annoying.

Re the patch:

I am being pedantic, I know, but for completeness...
free(c) should come before the test for s == nil,
as it could lead to a memory leak. reordering the code
fractionally fixes it.

 
 	c = Strtoc(&f->name);
-	sprint(buf, "%c%c%c %s\n", " '"[f->mod],
+	s = smprint("%c%c%c %s\n", " '"[f->mod],
 		"-+"[f->rasp!=0], " ."[f==curfile], c);
+	if(s == nil)
+		error(Etoolong);
 	free(c);

changes to 

 	c = Strtoc(&f->name);
-	sprint(buf, "%c%c%c %s\n", " '"[f->mod],
+	s = smprint("%c%c%c %s\n", " '"[f->mod],
 		"-+"[f->rasp!=0], " ."[f==curfile], c);
 	free(c);
+	if(s == nil)
+		error(Etoolong);


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

* Re: [9front] sam input line length limits
  2021-02-13 16:25   ` Steve Simon
@ 2021-02-13 20:06     ` ori
  2021-02-13 20:21       ` Stanley Lieber
  0 siblings, 1 reply; 7+ messages in thread
From: ori @ 2021-02-13 20:06 UTC (permalink / raw)
  To: 9front

Quoth Steve Simon <steve@quintile.net>:
> Normally I would be very wary of changing sam it has served
> me well for many years, but I am with you on this one,
> it has bitten me in the past and its annoying.
> 
> Re the patch:
> 
> I am being pedantic, I know, but for completeness...
> free(c) should come before the test for s == nil,
> as it could lead to a memory leak. reordering the code
> fractionally fixes it.

Yep, it definitely should. Thanks for looking.
I'll actually *run* the code today, and see if
I missed anything.


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

* Re: [9front] sam input line length limits
  2021-02-13 20:06     ` ori
@ 2021-02-13 20:21       ` Stanley Lieber
  0 siblings, 0 replies; 7+ messages in thread
From: Stanley Lieber @ 2021-02-13 20:21 UTC (permalink / raw)
  To: 9front

On February 13, 2021 3:06:22 PM EST, ori@eigenstate.org wrote:
>Quoth Steve Simon <steve@quintile.net>:
>> Normally I would be very wary of changing sam it has served
>> me well for many years, but I am with you on this one,
>> it has bitten me in the past and its annoying.
>> 
>> Re the patch:
>> 
>> I am being pedantic, I know, but for completeness...
>> free(c) should come before the test for s == nil,
>> as it could lead to a memory leak. reordering the code
>> fractionally fixes it.
>
>Yep, it definitely should. Thanks for looking.
>I'll actually *run* the code today, and see if
>I missed anything.
>
>

installed it yesterday, no reports of ill effects so far.

sl

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

end of thread, other threads:[~2021-02-14 14:45 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-13  0:45 [9front] sam input line length limits sl
2021-02-13  2:47 ` Nick Owens
2021-02-13  3:43 ` ori
2021-02-13  3:55   ` sl
2021-02-13 16:25   ` Steve Simon
2021-02-13 20:06     ` ori
2021-02-13 20:21       ` Stanley Lieber

9front - general discussion about 9front

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/9front

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 9front 9front/ http://inbox.vuxu.org/9front \
		9front@9front.org
	public-inbox-index 9front

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.9front


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git