On Thu, 10 Jan 2002, Nicholas Clark wrote:
> On Thu, Jan 10, 2002 at 03:06:38PM +, Alex Gough wrote:
> > Also, I'm a bit concerned that our null termination games:
> I would strongly recommend that perl6 mandates that buffers are not nul
> terminated. Anything that needs a nul should arrange
>
> I would strongly recommend that perl6 mandates that buffers are not nul
> terminated. Anything that needs a nul should arrange for one to be
appended.
> [eg by ensuring that the buffer is writable, extending it by one byte if
> needs be, and writing that nul, or by copying out the contents.]
>
At 02:33 PM 1/10/2002 +, Simon Glover wrote:
> This fixes a couple of nits in rx.c:
>
>1. There's no newline at the end, which makes gcc unhappy.
>2. We should use NULL, not 0 or "", for creating null pointers.
Applied, thanks.
Dan
--
On Thu, Jan 10, 2002 at 03:06:38PM +, Alex Gough wrote:
> Also, I'm a bit concerned that our null termination games:
>
> s->bufstart = mem_sys_allocate(buflen+1);
> ...
> memset((char *)s->bufstart+s->bufused,0,1);
>
> Are going to lead to an eternity of OBO errors. Also if our
On Thu, 10 Jan 2002, Simon Glover wrote:
>
> This fixes a couple of nits in rx.c:
patch seems fine, but got me thinking...
>2. We should use NULL, not 0 or "", for creating null pointers.
"" isn't a NULL pointer although at present there isn't any difference
in the result of
string_make(I
This fixes a couple of nits in rx.c:
1. There's no newline at the end, which makes gcc unhappy.
2. We should use NULL, not 0 or "", for creating null pointers.
Simon
--- rx.c.oldWed Jan 9 22:35:14 2002
+++ rx.cThu Jan 10 14:14:36 2002
@@ -76,9 +76,9 @@
/*p
