Date: Sat, 23 Mar 2002 15:01:05 +1100 From: "Tim J. Robbins" <tim@robbins.dropbear.id.au> To: "J. Mallett" <jmallett@FreeBSD.ORG> Cc: freebsd-audit@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Subject: Re: patch for review: xargs standards compliance Message-ID: <20020323150105.A3813@descent.robbins.dropbear.id.au> In-Reply-To: <20020322160631.A31375@FreeBSD.ORG>; from jmallett@FreeBSD.ORG on Fri, Mar 22, 2002 at 04:06:32PM %2B0000 References: <20020316192629.A5254@descent.robbins.dropbear.id.au> <20020316090004.A26394@FreeBSD.ORG> <xzpd6y4voj9.fsf@flood.ping.uio.no> <20020316093507.B26394@FreeBSD.ORG> <xzp8z8svni7.fsf@flood.ping.uio.no> <20020316101434.A2192@FreeBSD.ORG> <20020322035231.A23277@FreeBSD.ORG> <20020322160802.B1338@descent.robbins.dropbear.id.au> <20020322151214.A26549@FreeBSD.ORG> <20020322160631.A31375@FreeBSD.ORG>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 22, 2002 at 04:06:32PM +0000, J. Mallett wrote: > One thing I am now unsure of that I'd forgotten all about is: > "Constructed arguments cannot grow larger than 255 bytes. " > > Should I errx() if strlen(*tmp) is >255, or should I augment strnsubst() > to take a size argument and not allow more than that amount to be > allocated, and furthermore, do I strlcat replstr for each match, or do I > do checks along the way to see if it is time to give up on replacing, and > just concatenate the rest of the string. I *think* given the language > relating to umber of replacements in the argument list, that I should TRY > to replace as many times as possible, up to five... $ echo hello | xargs -I xxx echo `perl -e 'print "A"x255;'`xxx xargs: Maximum argument size with insertion via xxx's exceeded Segmentation Fault $ uname -sr SunOS 5.8 Since SUS is biased towards SysV, you should probably print an error message and exit like Solaris tries to; no need for you to segfault like they do though ;) Also: $ echo hello | xargs -Ixxx a xxx b xxx c xxx d xxx e xxx f xxx xargs: too many args with xxx So it seems you should quit with an error when either of these limits are reached. This seems to be a flaw in the standard because these limits are (a) artifically low and (b) cannot be raised by implementors. Tim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020323150105.A3813>