After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 639343 - FileStream read/write should have a different definition
FileStream read/write should have a different definition
Status: RESOLVED INVALID
Product: vala
Classification: Core
Component: Bindings: GLib
0.11.x
Other Linux
: Normal normal
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2011-01-12 18:57 UTC by Marco Trevisan (Treviño)
Modified: 2011-01-16 07:36 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Marco Trevisan (Treviño) 2011-01-12 18:57:46 UTC
Actually FileStream.write is defined as (the same is for the read function):
[CCode (cname = "fwrite", instance_pos = -1)]
public size_t write ([CCode (array_length_pos = 2.1)] uint8[] buf, size_t size = 1);

However fwrite/fread are defined as:

size_t fwrite(const void *ptr, size_t size, size_t nmemb, FILE *stream);

DESCRIPTION
       The  function  fread()  reads  nmemb elements of data, each size bytes
       long, from the stream pointed to by stream, storing them at the  loca‐
       tion given by ptr.


So the definition should be:
[CCode (cname = "fwrite", instance_pos = -1)]
public size_t write (uint8[] buf, size_t nmemb = 1; [CCode (pos = 2.1)] size_t size = 1);

or at least:
[CCode (cname = "fwrite", instance_pos = -1)]
public size_t write ([CCode (array_length_pos = 1.1)] uint8[] buf, size_t num_elements = 1);

Or something similar, since the size of an element of an uint8 array is always 1, the only value that is needed to be set is the number of items of the array to write.

In the current situation, in fact, for writing just some bytes of an array we need to do something like:
   stdout.write(buf[0:NUMBER_OF_ELEMENTS_TO_WRITE]);

And this is not so friendly, since these function would support that natively...
Comment 1 Evan Nemerson 2011-01-16 07:36:14 UTC
(In reply to comment #0)
> So the definition should be:
> [CCode (cname = "fwrite", instance_pos = -1)]
> public size_t write (uint8[] buf, size_t nmemb = 1; [CCode (pos = 2.1)] size_t
> size = 1);

This will cause a compiler error because of the extra argument. Also, size and nmemb are reversed... I'm assuming you're going for something like this:

[CCode (cname = "fwrite", instance_pos = -1)]
public size_t write ([CCode (array_length = false)] buf, size_t size = 1, size_t nmemb = 1);

I think most of the time people want to write the entire array, which you can currently do by passing a single argument. I don't see the benefit of forcing people to write buf, buf.length constantly instead of buf[0:X] on those rare occasions when they do want to write only a slice of the array... especially when you consider that if you really want to write only a subset of the array you're probably going to want to start from an offset quite often, which means you're going to have to use array slicing regardless. Furthermore, this will break backwards compatibility.

> or at least:
> [CCode (cname = "fwrite", instance_pos = -1)]
> public size_t write ([CCode (array_length_pos = 1.1)] uint8[] buf, size_t
> num_elements = 1);
> 
> Or something similar, since the size of an element of an uint8 array is always
> 1, the only value that is needed to be set is the number of items of the array
> to write.

Practically, how is this any different from what currently exists? You're doing this

fwrite (buf, buf_length, num_elements, fp);

instead of

fwrite (buf, size, buf_length, fp);

> In the current situation, in fact, for writing just some bytes of an array we
> need to do something like:
>    stdout.write(buf[0:NUMBER_OF_ELEMENTS_TO_WRITE]);
> 
> And this is not so friendly, since these function would support that
> natively...

You're trying to optimize the function definition for the corner case instead of the common case. And break backwards compatibility in the process... Perhaps I'm missing something, but I don't see the benefit.