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
Best
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>);
J.