Re: [dev] stderr: unnecessary?

Kris, Kris, Kris...

So no one in the world ever reads files bigger than 2GB? That's a
silly notion. You can't design an API based on what you think a
programmer is _most likely_ to need, without consideration to other
scenarios. At least not if you want it to be scalable enough to be
relevant in a few years. The UNIX people understand that, and that's
why UNIX-like operating systems are still in use after decades.

As for the OP: People have given a few good reasons why stderr is
useful, and that's why it's around. Couldn't have said it better
myself.

On 6/11/10, Kris Maglione <maglione.k_AT_gmail.com> wrote:
> On Fri, Jun 11, 2010 at 06:19:18PM +0200, pancake wrote:
>>On 06/11/10 15:21, Moritz Wilhelmy wrote:
>>
>> unsigned int read(int fd, ref char *buf, unsigned int buf_len, GError
>> **err);
>>
>>(yeah, thats a silly example, but it allows you to make reads
>>bigger than 31 bits without having to check for the return
>>value) In other situations it is good to handle errors in this
>>way, but thinking on some restrictions allows you to mix error
>>values and data in the same pipe.
>
> ((1<<31)-1) / (1<<30) ≅ 2GB.
>
> I'm not seeing a major problem here. At any rate, the GError
> arguments is more about a disdain for errno than anything else.
> It's the same reason that Go, Limbo, and Common Lisp support
> multiple return values.
>
> --
> Kris Maglione
>
> The first symptom of love in a young man is shyness; the first symptom
> in a woman, it's boldness.
> --Victor Hugo
>
>
>
Received on Fri Jun 11 2010 - 16:59:45 UTC