NetSurf 3.6 web browser released!

[olsen]

Ah, looks like strftime gets replaced. Before I change this, do you know if this comment is valid?

Code: [Select]

/* Although these platforms might have strftime or strptime they
 *  appear not to support the time_t seconds format specifier.
 */

Yes, this is still valid. clib2 does not support the strftime() "%s" conversion specifier. "%s" appears to be a Unix addition, and it is not part of the C99 specs. I could easily add it, though, if it is needed.

Looking at the source code of NetSurf 3.6, it appears that there is a workaround in place which performs the conversion with snprintf(). Makes you wonder why strftime() is used in the first place

As for strptime(), this is not part of the C99 specs either, and quite complex to implement. This seems to be a Unix addition, too. Again, NetSurf has various workarounds for strptime() in place which do the job just fine.

NetSurf neither replaces vsnprintf() nor strftime(), as far as I can tell. There goes my theory as to what interferes with the JSON data generation. I'm really puzzled how this could go so spectacularly awry... Could you check the linker map? It should show where the vsnprintf() and strftime() code comes from, exactly.

That said, it's not difficult to generate the same data using the __get_slab_allocations() and __get_slab_usage() API functions in clib2 if you wanted to implement it yourself. I just thought I'd save you the effort and put it into __get_slab_stats().

[olsen]

@olsen
I'm afraid the map file means nothing to me, but it's here if you want to decode it: http://www.cy2.uk/tmp/map.txt.gz

Thank you, it's not that cryptic, it's just too long

Here are the "interesting" bits (for given values of "interesting"):

-- 8< --

 .text          0x0056a724       0x90 /opt/netsurf/m68k-unknown-amigaos/cross/lib/gcc/m68k-unknown-amigaos/3.4.6/../../../../m68k-unknown-amigaos/lib/libm.a()
                0x0056a724                _vsnprintf

 .text          0x005886e0      0xe98 /opt/netsurf/m68k-unknown-amigaos/cross/lib/gcc/m68k-unknown-amigaos/3.4.6/../../../../m68k-unknown-amigaos/lib/libc.a(time_strftime.o)
                0x00589408                _strftime

-- 8< --

This says that both vsnprintf() and strftime() come from the libm.a and libc.a linker libraries, which are part of clib2, etc. It's odd that the reference to libm.a does not list the source file name (when did you last rebuild all these libraries from scratch?).

Anyhow, these library functions are not getting overridden by NetSurf, libcurl, libssl, libgcc, etc. code.

Which collapses another theory of mine.

How does the code look like which fails to produce the correct JSON data? Have you already checked it in?

[olsen]

It's checked in, here it is:

Code: [Select]


static int ami_memory_slab_stats_cb(void *user_data, const char *line, size_t line_length)
{
BPTR fh = (BPTR)user_data;
long err = FPuts(fh, line);

if(err != 0) {
return -1;
} else {
return 0;
}
}

fh = Open(fname, MODE_NEWFILE);
__get_slab_stats(fh, ami_memory_slab_stats_cb);
Close(fh);


Thank you, this looks like it should.

This suggest that the problem may be with the clib2 vsnprintf() code. I only tested the plain libc version (no floating point support), whereas NetSurf uses the libm version (with floating point support). I'll have another go at reproducing the problem.

One last thing: does the behaviour change in any way if you replace Open()/FPuts()/Close() with fopen()/fputs()/fclose(), or store the file on a different volume (i.e. don't save to RAM:, save to a hard disk drive)?