On 3 Aug 2007, at 15:14, Peter da Silva wrote:
Ultimately, though, something like this structure tends to raise
its head:
struct _buffer {
int size; // size of buffer
int length; // size of data in buffer
#ifdef BUFFERGAP
int gap;// start of gap
#endif
#ifdef RESIZABLE
ch
On 03-Aug-2007, at 08:50, Andy Armstrong wrote:
Are we still arguing about program args or am I right in thinking
we've moved on to strings in general?
The hate in question is still xargs. However...
With Pascal strings a function that trims leading spaces has to
return a new string - with
On 3 Aug 2007, at 14:28, David Cantrell wrote:
On Fri, Aug 03, 2007 at 07:23:55AM -0500, Peter da Silva wrote:
On Aug 3, 2007, at 6:47, David Cantrell wrote:
On Thu, Aug 02, 2007 at 02:32:20PM -0500, Peter da Silva wrote:
Please have the length of strings upfront.
Length encoding isn't self-s
On 03-Aug-2007, at 08:28, David Cantrell wrote:
I want only one kind of string thankyouverymuch.
That's precisely my point.
If this was RSX-11 or the UCSD P-System, counted strings would make
sense. Trying to improve part of a system and in the process making
it inconsistent and incompatib
On Fri, Aug 03, 2007 at 07:23:55AM -0500, Peter da Silva wrote:
> On Aug 3, 2007, at 6:47, David Cantrell wrote:
> >On Thu, Aug 02, 2007 at 02:32:20PM -0500, Peter da Silva wrote:
> >>> Please have the length of strings upfront.
> >>Length encoding isn't self-syncing,
> >Better that than not being
On Aug 3, 2007, at 6:47, David Cantrell wrote:
On Thu, Aug 02, 2007 at 02:32:20PM -0500, Peter da Silva wrote:
Please have the length of strings upfront.
Length encoding isn't self-syncing,
Better that than not being able to easily pass arbitrary data, which
might include NULLs.
As para
On Thu, Aug 02, 2007 at 02:32:20PM -0500, Peter da Silva wrote:
> > Please have the length of strings upfront.
> Length encoding isn't self-syncing,
Better that than not being able to easily pass arbitrary data, which
might include NULLs.
> and it also limits
On Aug 3, 2007, at 0:59, A. Pagaltzis wrote:
* Peter da Silva [2007-08-02 21:45]:
Please have the length of strings upfront.
Length encoding isn't self-syncing,
Synching the length is O(1).
Can you elaborate on that comment, because I don't see how you can in
principle resync a stream
On 8/3/07, A. Pagaltzis wrote:
> * Peter da Silva [2007-08-02 21:45]:
> > > Please have the length of strings upfront.
> >
> > Length encoding isn't self-syncing,
>
> Synching the length is O(1).
>
> Not doing it makes *everything* O(n) and leaves you to deal with
> the semi-predicate problem, s
* Peter da Silva [2007-08-02 21:45]:
> > Please have the length of strings upfront.
>
> Length encoding isn't self-syncing,
Synching the length is O(1).
Not doing it makes *everything* O(n) and leaves you to deal with
the semi-predicate problem, source of lots of 'sploits and other
fun for the
Peter da Silva wrote:
> On Aug 2, 2007, at 9:29, Jarkko Hietaniemi wrote:
>>> a "stdcmd" stream that let you read a *genuinely* unlimited stream of
>>> null-terminated parameters. In the absence of that, handcraft it
>
>> Your C is showing.
>
> It's UNIX, there's so many places where the requirem
Peter da Silva wrote:
[snip]
An unlimited command line is impossible, and hideously inefficient.
Eventually you'll run out of VM building the command line, no matter how
much VM you have. You have to get away from the whole concept of the
command line to resolve that problem.
If something is
12 matches
Mail list logo
