On Wed, 2012-04-18 at 10:27 +0200, Svante Signell wrote:
Your patch would make use of /proc/curproc/file, which would seem to be
part of the FreeBSD procfs[1]; our procfs is more oriented to emulate
Linux's one, so IMHO we should either use the Linux code, or add an
empty
On Wed, 2012-04-18 at 09:54:55 +0200, Pino Toscano wrote:
Now that I saw webkit's code, I'm a bit dubious about the code in
Source/JavaScriptCore/wtf/gobject/GlibUtilities.cpp; it basically does
something like this (simplified for convenience of email):
| #if OS(LINUX)
| CString
Alle martedì 17 aprile 2012, Svante Signell ha scritto:
BTW: Doesn't the CString resultString; need to be initialized?
Or something like:
if (result = 0 result sb.st_size)
resultString = CString(readLinkBuffer, result);
else
resultString = CString();
The else branch is not needed,
On Wed, 2012-04-18 at 09:54 +0200, Pino Toscano wrote:
Alle martedì 17 aprile 2012, Svante Signell ha scritto:
The else branch is not needed, resultString is already initialized.
Initialized to the empty string, or?
C++ (just like C99, FWIW) allows to declare variables inside code
blocks,
On Mon, 2012-04-16 at 23:00 +0200, Samuel Thibault wrote:
Pino Toscano, le Mon 16 Apr 2012 22:51:01 +0200, a écrit :
... but then you leak readLinkBuffer in both the cases (error return
value from readlink(), and success); you can do something like this:
| CString resultString;
| if
Source: webkit
Version: 1.8.0-2
Severity: Important
Tags: hurd
User: debian-hurd@lists.debian.org
Managed to build webkit with 2G of RAM, and 2.6G of swap. Total disk
size around 10G. The files libwebkitgtk-1.0.so.0.13.1 and
libwebkitgtk-3.0.so.0.13.1 are around 1G each! (unstripped) Couldn't
On Mon, 2012-04-16 at 17:43 +0200, Samuel Thibault wrote:
Svante Signell, le Mon 16 Apr 2012 17:38:03 +0200, a écrit :
Managed to build webkit with 2G of RAM, and 2.6G of swap. Total disk
size around 10G. The files libwebkitgtk-1.0.so.0.13.1 and
libwebkitgtk-3.0.so.0.13.1 are around 1G
Svante Signell, le Mon 16 Apr 2012 18:07:54 +0200, a écrit :
No, doesn't look like it (from the ChangeLog):
Ok.
Problem with the patch is that the allocated string cannot easily be
freed:
You mean the string allocated in getCurrentExecutablePath()? It's fine
to keep it allocated
On Mon, 2012-04-16 at 19:21 +0200, Samuel Thibault wrote:
Svante Signell, le Mon 16 Apr 2012 18:07:54 +0200, a écrit :
No, doesn't look like it (from the ChangeLog):
Ok.
The only definition of *PATH_MAX to 1024 is in the autotools stuff!
Source/autotools/ltmain.sh:
#if defined(PATH_MAX)
#
Svante Signell, le Mon 16 Apr 2012 19:36:29 +0200, a écrit :
char *readLinkBuffer; - static char *readLinkBuffer;
similar to static char readLinkBuffer[PATH_MAX]; before?
Yes.
So static works even if the memory allocated for the buffer is
malloced?? Of course the pointer remains the same,
Hi,
(interesting you sent your initial patch, with no changes...)
Alle lunedì 16 aprile 2012, Svante Signell ha scritto:
Problem with the patch is that the allocated string cannot easily be
freed:
Sure it can.
The string str is declared const char* and I don't want to change
that
Pino Toscano, le Mon 16 Apr 2012 22:51:01 +0200, a écrit :
... but then you leak readLinkBuffer in both the cases (error return
value from readlink(), and success); you can do something like this:
| CString resultString;
| if (result = 0 result sb.st_size)
| resultString =
12 matches
Mail list logo
