Hi!
Since _g_file_attribute_value_set_from_pointer uses g_strdupv,
value-u.stringv may be NULL. _as_string does a
for (i = 0; attr-u.stringv[i] != NULL; i++)
without first checking that attr-u.stringv isn’t NULL, a potential
NULL-pointer dereference.
Correct?
On Wed, Oct 8, 2008 at 13:20, Havoc Pennington [EMAIL PROTECTED] wrote:
On Tue, Oct 7, 2008 at 5:50 PM, Brian J. Tarricone [EMAIL PROTECTED] wrote:
I think what he really meant (or if not, here's my take on it) was that NUL
bytes aren't *printable* text... like you'd say of low-value ASCII
On Dec 5, 2007 3:47 PM, Morten Welinder [EMAIL PROTECTED] wrote:
Perhaps beside the point, but one wouldn't introduce this problem had
one written
#define stat(path, buf) stat64(path, buf)
Not in the case of stat, certainly. struct stat needs to work.
Oh, my.
On Dec 5, 2007 3:24 PM, Morten Welinder [EMAIL PROTECTED] wrote:
Specially as you can use #undef in your C code, when stuck with a
platform doing such stupidities...
Aha, a member of the standards-don't-apply-to-me school, :-)
Yes, you might #undef, but then you would not be able to use
Hi!
I have written a library [1] that is currently under consideration for
(at least partial) inclusion in Ruby 2.0 [2]. I used GLib as a
reference implementation while writing this library and I am thus
wondering exactly how licensing works in this situation.
GLib is released under the LGPL
On 3/16/07, Mathieu Lacage [EMAIL PROTECTED] wrote:
On Thu, 2007-03-15 at 10:56 -0400, Owen Taylor wrote:
Well, I could imagine (maybe, barely) that someone could show me numbers
that showed that with a variety of long and complicated regular
expressions, compiling them was still 10x as
On 2/26/07, Alexander Larsson [EMAIL PROTECTED] wrote:
On Sat, 2007-02-24 at 14:18 +0100, Nikolai Weibull wrote:
On 2/24/07, Hans Petter Jansson [EMAIL PROTECTED] wrote:
On Fri, 2007-02-23 at 10:56 +0100, Alexander Larsson wrote:
On Thu, 2007-02-22 at 17:44 -0600, Hans Petter Jansson
On 2/24/07, Hans Petter Jansson [EMAIL PROTECTED] wrote:
On Fri, 2007-02-23 at 10:56 +0100, Alexander Larsson wrote:
On Thu, 2007-02-22 at 17:44 -0600, Hans Petter Jansson wrote:
So I guess our default would be ~/.local/share/vfs/ ?
XDG_DATA_HOME is basically the user-specific version of
On 2/22/07, Hans Petter Jansson [EMAIL PROTECTED] wrote:
~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt
I just want to point out that there's a freedesktop specification for
where things should be stored. Not many seem to respect it, but I,
for one, really would appreciate
On 13 Feb 2007 19:14:06 +0100, Soeren Sandmann [EMAIL PROTECTED] wrote:
Splay trees are only faster in the case where
- the comparison function is really slow
My point was that if nothing can be done to speed up the comparison
function, then treaps lose.
nikolai
On 13 Feb 2007 03:46:11 +0100, Soeren Sandmann [EMAIL PROTECTED] wrote:
GSequence is currently implemented with a splaytree which, even though
it is a neat data structure, has some downsides:
* They are only O(log n) in the amortized sense
This means individual operations can take a long
On 1/6/07, Owen Taylor [EMAIL PROTECTED] wrote:
On Sat, 2007-01-06 at 04:44 -0800, Sergei Steshenko wrote:
FWIW, 'konqueror' WEB browser doesn't appear to leak, while gtk+-based
Mozilla, Firfox, Seamonkey leak a lot, and I'm not sure whether it's
'Gecko' or gtk+ issue.
The memory usage
On 1/6/07, Owen Taylor [EMAIL PROTECTED] wrote:
On Sat, 2007-01-06 at 04:44 -0800, Sergei Steshenko wrote:
FWIW, 'konqueror' WEB browser doesn't appear to leak, while gtk+-based
Mozilla, Firfox, Seamonkey leak a lot, and I'm not sure whether it's
'Gecko' or gtk+ issue.
The memory usage
On 10/27/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I ve build a gtk_aplication that consist in plot points in a graphic...i'd
like
to insert a cursor to can jump throught the points.
how can i do it??
BY SHOUTING REALLY LOUD !!
OR ASKING ON THE APPROPRIATE LIST, LIKE
Hi!
Perhaps this should only go to the xdg list, but seeing as you've
already taken matters into your own hands I'm mailing here as well.
The issue is the name and location of the recently-used file. In
2.10.0, the location changed to ~/.recently-used.xbel. Version 0.2 of
the Recent File
15 matches
Mail list logo
