Hi John-Mark,

The only reason I would have been shy of malloc() – as well as the fact that the fixed-length is how it was written in browser_window_go_post() – would be that stack allocation is normally much faster, plus it's, I suppose, a local variable, so the stack memory taken is quickly released? Though I'm not sure how that interacts with the const definition in void gui_window_set_url(struct gui_window *_g, const char *url); [gtk_scaffolding.c 1418] memory allocation in C not being the easiest job to get just right :-)

As it's currently a tiny amount of memory, the RISC OS limit you referred to may be the most important factor, unless you really want it changed for the sake of tidiness



Key ID 046B65CF

John-Mark Bell - jmb@ecs.soton.ac.uk wrote:
On Sun, 2009-03-29 at 19:24 +0200, netsurf.list.markie1@dfgh.net wrote:

John-Mark Bell - jmb@netsurf-browser.org wrote:
+               browser_window_update(bw);
Can you explain why this is needed? You mentioned something about the
first tab being odd.
It is, the LHS of the page draws, not the RHS; though that
browser_window_update() call has no effect, even putting it ahead of
the conditional;

Ok. That's something else entirely. I believe that Mike Lester has a fix
for that. Mike?

here's the patch re-improved, slimmed down

Thanks. Modulo the fixed-size buffer, that looks fine. I suspect the
solution to the fixed buffer is buf = malloc(strlen(url) +
strlen(frag_id) + <length of separators + \0>);