bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The patch of pfinet


From: olafBuddenhagen
Subject: Re: The patch of pfinet
Date: Tue, 12 Aug 2008 00:21:30 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hi,

On Mon, Aug 11, 2008 at 05:56:40PM +0200, zhengda wrote:
> olafBuddenhagen@gmx.net wrote:
>> On Fri, Aug 08, 2008 at 08:09:24AM +0200, zhengda wrote:

>>> -  err = get_privileged_ports (0, &master_device);
>>> -  if (err)
>>> -    error (2, err, "cannot get device master port");
>>> +  if (master_device_file)
>>> +    {
>>> +      master_device = file_name_lookup (master_device_file , 0 , 0);
>>> +      if (master_device == MACH_PORT_NULL)
>>> +        error (10, 0, "file_name_lookup %s", master_device_file);
>>> +    }
>>> +  else
>>> +    {
>>> +      err = get_privileged_ports (0, &master_device);
>>> +      if (err)
>>> +        error (2, err, "cannot get device master port");
>>> +    }
>>>     
>>
>> Is it really appropriate to use a different error code in the case of
>> using an alternate master device port?...
>>   
> I don't know how to use the error code properly. what is the rule to
> use it?

I don't know the rule either, if there is any... But it just seems
reasonable to be consistent and use the same error code for an
equivalent error condition...

> so is the correct copyright statement something like this?
> /*
>   Copyright (C) 2008
>   Free Software Foundation, Inc.
>
>   Written by Zheng Da.
>
>   This file is part of the GNU Hurd.
> ...

Yes, for files written from scratch, this is correct.

"Copyright (C) 2008 Free Software Foundation, Inc." usually goes on one
line, though -- it only got wrapped in some places because the line
simply got too long :-)

>>> +  insn = (struct bpf_insn *) malloc ((program.bf_len + 1) * sizeof
>>> (*insn));
>>>     
>>
>> Your mail client mangled the patch, inserting a spurious linebreak.
>> (Also happened in a few other places.)
>>   
> I guess the reason is that the line is a little long, and my mail
> client  break it automatically.

Indeed.

> Do you have any idea to prevent the mail client to do it? I use
> thunderbird. I didn't find anything that can switch this function off.

No idea about Thunderbird... But this is probably a reason why few
hackers use Thunderbird.

With Mutt for example, you just edit the message body with your
favourite text editor, and Mutt will send it as is, never messing with
the formatting. Mutt is a bit of a learning curve, though...

Perhaps Thunderbird will also do it right, if you tell it to use an
external editor instead of the integrated one? (Might require installing
an extension, not sure.)

-antrik-




reply via email to

[Prev in Thread] Current Thread [Next in Thread]