Re: libegg/recentchooser
Hi James,
On Wed, 2005-11-30 at 11:23 +0800, James Henstridge wrote:
> Emmanuele Bassi wrote:
>
> >Uhm, I'll put that code under #idef G_OS_UNIX/#endif guards for the time
> >being, but the getenv("TZ")/setenv("TZ") timezone trick should work on
> >any sufficiently recent POSIX-like system; users of other operating
> >systems might just drop me an email.
> >
> >We could just define a GDate function for this date transformation, by
> >the way, since every project that has to deal with ISO8601 dates might
> >eventually benefit of this code.
> >
> >
> There is an ISO8601 date parser in libsoup that might be worth looking
> at. If you just want an mktime() equivalent that handles UTC, see
> soup_mktime_utc().
Thank you, I'll have a look at it immediately.
Ciao,
Emmanuele.
--
Emmanuele Bassi - <[EMAIL PROTECTED]>
Log: http://log.emmanuelebassi.net
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Make g_rename() replace existing files on Win32?
On 30/11/05 00:54:22, Tor Lillqvist wrote: The rename() function in the Microsoft C library calls the Win32 API MoveFile(), which does not replace existing files. I now notice there is also a function MoveFileEx(), to which one can specify the flag MOVEFILE_REPLACE_EXISTING, which enables atomic replacement of an existing file. Sigh, why didn't I notice that earlier... What do you think, should g_rename() be changed to use MoveFileEx() instead of rename() on NT-based Windowses? My vote is yes. And mine too. The advantages outweigh the tiny API breakage. Cheers, Ali. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: comments on g_list_slice / g_list_splice
On Wed, 30 Nov 2005 00:57:42 -0500 "ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN" <[EMAIL PROTECTED]> wrote: > GList * g_list_slice(GList *list, GList *link, gint n_links); > GList * g_list_remove_slice(GList *list, GList *link, gint n_links); > > GList * g_list_splice(GList *list, GList *splice_list, gint position); > GList * g_list_splice_before(GList *list, GList *splice_list, GList > *sibling); I added myself GPtrArray* g_ptr_array_slice(const GPtrArray* orig, guint first, gint last); I have found it more useful to pass offset indexes. For arrays this is the only sensible choice, but for lists it's somewhat harder to say what is the correct way of "indexing" them. Offset count, or link node pointer? Either way, the presence of functions which do that job, sound very useful. -- Paul "LeoNerd" Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Fwd: Re: comments on g_list_slice / g_list_splice
I just realized that all of the APIs need to return the original list because it can be modified. The way I'm playing with it now, the slice calls would simply unlink 'link' and it is up to the caller to reuse the same 'link' pointer as the newly separated list.. - Original Message - From: Paul Leonerd Evans <[EMAIL PROTECTED]> At: 11/30 5:49 On Wed, 30 Nov 2005 00:57:42 -0500 "ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN" <[EMAIL PROTECTED]> wrote: > GList * g_list_slice(GList *list, GList *link, gint n_links); > GList * g_list_remove_slice(GList *list, GList *link, gint n_links); > > GList * g_list_splice(GList *list, GList *splice_list, gint position); > GList * g_list_splice_before(GList *list, GList *splice_list, GList > *sibling); I added myself GPtrArray* g_ptr_array_slice(const GPtrArray* orig, guint first, gint last); I have found it more useful to pass offset indexes. For arrays this is the only sensible choice, but for lists it's somewhat harder to say what is the correct way of "indexing" them. Offset count, or link node pointer? Either way, the presence of functions which do that job, sound very useful. -- Paul "LeoNerd" Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list signatur.asc Description: Binary data ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: g_list_first()
Hello, What did you need to do exactly
If you need to test all elements in a single list and delete elements you
whish you can use this type of code, it isn't optimised but it work's, else
you can use g_list_foreach to apply a personnal function at each element of
your GSList but it doesn't work for deleting GSList.
If you need any explanation mail me.
static GSList* _your_function(GSList* list, gint X)
{
GSList *saveList=list,*buflist=list;
while(list)
{
if( your_test ) //(list->data < X) for example
{
gfree(list->data);
if(list==buflist) // case of first element of the list, we don't loose
the begin of the list
{
saveList=list->next;
buflist=list->next;
gfree(list);
list=buflist;
}
else
{
buflist->next=list->next; //if you need to free the list,
update the next element of the preceding list
gfree(list);
list=buflist->next;
}
}
else
{
buflist=list;
list=list->next;
}
}
return saveList;
}
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Call-return interface for file choosers? (and: security using powerboxes)
David Malcolm <[EMAIL PROTECTED]> wrote: > How about a slightly different interface where you work with > buffers/memory mapped files/file handles/something other than filenames? > This way the application doesn't need to be able to open the user's > files for reading/writing; the trusted executable can do this for it. > > A naive interface might be something like this: > gboolean foo_open_file (void **return_buffer, size_t *return_size); > gboolean foo_save_file (void *content, size_t size); > which could internally handle the necessary IPC; though obviously this > needs work so that it doesn't block the application's redraws etc etc. Yes, this is similar to how Plash works internally. Plash has file objects, and you can pass a reference to a file object between processes. Plash implements the POSIX API in terms of these file objects. A file object has an "open" method which returns a file descriptor for reading or writing the file. The interface you're suggesting removes the need for passing file descriptors. That would be advantageous because kernel-level file descriptors are not revokable (which could be fixed if the kernel provided a way to create revokable proxies for FDs). On the other hand, it might have worse performance, but this probably wouldn't be serious if it was limited to a read_whole_file()/write_whole_file() style interface. The reason for using filenames is just that programs are written to use filenames. I'm trying to get programs to use the powerbox with the minimum changes possible. Later on, it would be good if programs were changed to use object references for files instead of filenames. This can help solve some problems. It makes it easier to determine when the right to access a file should be transferred to another process. Using object references is better when you're trying to write a program that must deal with requests on behalf of multiple mutually-untrusting parties. This is why setuid programs have traditionally been hard to write correctly: When a setuid process uses a filename, the OS checks whether the process as a whole has permission to access the file, not whether the filename came from a source which could access the file. So you can often fool a setuid program into misusing its authority. This is known as the "Confused Deputy" problem. It can be solved if you use object references for files where the right to access the file is bundled with the object reference. > Have you also thought about drag and drop from file managers? When > someone drags a file to your untrusted application, the application > receives a URL, but it needs some kind of permission to read the file as > well. Yes, eventually doing drag-and-drop with a file should transfer the right to access the file. Drag-and-drop is a really good user interface for transferring authority. There are some complications though. I think the X drag-and-drop protocols rely on X's lack of security. We're going to have to limit applications' ability to send X messages to each other. It may be necessary to create a new drag-and-drop protocol, and change apps or libraries to use it. Or it may be possible to handle this entirely in an X proxy, if that is how X access control is going to be achieved. > > Suppose you run Gnumeric to view a spreadsheet you downloaded from the > > Internet. Gnumeric might not be a malicious program, but suppose it > > has a buffer overrun bug (quite possible considering it's written in > > C), and the spreadsheet exploits that bug. > > IMHO Evolution is a better example; it's constantly working with data > from the network, and you rarely need to deal with arbitrary > user-readable files (creating attachments is one of the few cases)... > and it's written in C. Good point. Cheers, Mark ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib Bug: IO Channel cannot work with files larger that 2GB
Hi all,
There seems to be a bug with the IO Channel functions in Glib version 2.8.4
for Windows. This bug prevents seeking in files greater than 2GB in size,
i.e. where a 64-bit file pointer would be required.
The following snip of code will work if 'file_channel' refers to a file of
less than 2GB in size, however for a larger file, say 8GB the call to
g_io_channel_seek_position() will fail and gerror will contain
G_IO_CHANNEL_ERROR_INVAL.
GError *gerror = NULL;
gint64 seek_offset = -22;
if (g_io_channel_seek_position(file_channel, seek_offset, G_SEEK_END,
&gerror) != G_IO_STATUS_NORMAL)
{
crash_and_burn();
}
Is this a known bug/issue or am I missing something?
Regards,
Chris
smime.p7s
Description: S/MIME cryptographic signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib Bug: IO Channel cannot work with files larger that 2GB
Chris Morrison writes: > Is this a known bug/issue or am I missing something? Yes. Large file support is missing from the Win32 port. Sorry. It might be possible to do some fixes here and there without needing any new API or breaking ABI, like using _lseeki64() instead of lseek() in giowin32.c. (I probably should do that, or can anybody think of any bad consequences?) But there will still be other problems, like that g_stat() uses plain struct stat and not struct _stati64. --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: libegg/recentchooser
> Uhm, I'll put that code under #idef G_OS_UNIX/#endif guards for the time
> being, but the getenv("TZ")/setenv("TZ") timezone trick should work on
> any sufficiently recent POSIX-like system; users of other operating
> systems might just drop me an email.
setenv isn't POSIX. You can probably just use g_setenv although
that will leak.
But really, just do it as
((days_since_19700101 * 24 + h) * 60 + m) * 60 + s
where days_since_19700101 comes out of GDate.
M.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
