Re: g_file_write()
- From: Iago Rubio <iago rubio hispalinux es>
- To: "Gustavo J. A. M. Carneiro" <gjc inescporto pt>
- Cc: gtk-devel-list gnome org
- Subject: Re: g_file_write()
- Date: Mon, 07 Mar 2005 15:43:31 +0100
On Mon, 2005-03-07 at 11:49 +0000, Gustavo J. A. M. Carneiro wrote:
> On Mon, 2005-03-07 at 10:10 +0100, Iago Rubio wrote:
> > Nice job :)
> >
> > I really like to see file write operations on glib, but I don't know if
> > the function's name is the best to use.
> >
> > It seems that g_file_write should be something like the write()
> > function, so you can get an file descriptor with g_fopen() and write to
> > it.
>
> We already have fwrite and fread in libc, which AFAIK are completely
> portable.
I've seen old implementations returning int instead size_t, but well, as
it's ANSI and POSIX, yes it's "completely" portable.
But try to fwrite "\n" on linux and windows when the file is opened in
text mode, and you'll see that's no as portable as you think - I mean
you'll get different outputs on the same function/parameters.
You'll also get a bogus return value on Windows, as the written
characters can be more than the returned size_t bytes.
ITOH I'm not speaking about to wrap fwrite.
> No need to replicate this in glib just to get a silly g_
> prefix <wink/>
May be we can get not just a silly g_ but a consistent g_ with GError
checking, and other g_ nice things.
And as I said I'm not speaking about to wrap fwrite. May be
g_fwrite_to_filedes could be more explicative.
> > May be g_fwrite() is also needed to diferentiate it from g_file_write
> > () ?
> >
> > It'll give users the ability to write to the file (descriptor) in the
> > same way they used the write() function, so it can be used in loops with
> > no need of filling memory to get the whole buffer to write to the file.
>
> What you're describing sounds like GLib's GIOChannel's.
I don't think so.
GIOChannels are much more complex and less portable than what I'm
describing.
> > The current patch will be memory hungry on really large files, as the
> > buffer should be the entire file on memory.
>
> Then this should be mentioned in the documentation, that's all. The
> API doesn't have to apply to all use cases.
OK, that's right. Take it easy.
I'll not argue on this anymore, I've got no time to try to change
anyones mind.
Have a nice day.
--
Iago Rubio
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]