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
Best
Mark
http://www.halloit.com
Key ID 046B65CF
John-Mark Bell - jmb(a)ecs.soton.ac.uk wrote:
On Sun, 2009-03-29 at 19:24 +0200, netsurf.list.markie1(a)dfgh.net
wrote:
> John-Mark Bell - jmb(a)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.