All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: grub-devel@gnu.org
Subject: Re: Two Small Patches (x86 VolId & Sun Label Checking)
Date: Sun, 26 Dec 2010 11:41:00 +0100	[thread overview]
Message-ID: <4D171BBC.9000506@gmail.com> (raw)
In-Reply-To: <201012260529.oBQ5Tj6w069781@m5p.com>

[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]

On 12/26/2010 06:29 AM, ehem+grub@m5p.com wrote:
>
>>> stage. Second, perhaps minor, but I'm surprised someone chose to break
>>> the checksum verification code in grub-core/partmap/sun.c and didn't
>>> didn't keep the magic number check with it.
>>>       
>   
>> This seems to be just moving the code around. There are many different
>> coding styles. Changing from one of them to another is waste of effort
>> unless it's done to uniformise with rest of codebase. I don't have
>> strong preference to one or another style so I prefer not to touch anything.
>>     
> Leaving it alone for now is fine by me. I just found it rather strange to
> see two distinct styles in the exact same bit of code. I'd expect either
> all of the verification or none of the verification broken into a
> distinct function.
>
>   
checking magic number is a simple check (a == b) whereas checksum check
is a composite (you need to compute checksum first) so moving checksum
out in a separate function makes sense
> I will in fact be implementing breaking detection functions into distinct
> functions uniformly,
I'm not fond of "let's change it just because we can". There are much
more real tasks on the project. Come to #grub and I'm sure will find
something for you.
>  because there is a deeper issue lurking here. Looks
> to be pure luck no one ran into an unpleasant bug lurking in the existing
> design.
>
>   
Please show me the real problem then.
> (I can readily provide an illustration of the lurking landmine, later
> though)
>
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

  reply	other threads:[~2010-12-26 10:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-17  5:19 Two Small Patches (x86 VolId & Sun Label Checking) ehem+grub
2010-12-25 17:34 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-12-26  5:29   ` ehem+grub
2010-12-26 10:41     ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2010-12-26 21:15       ` ehem+grub
2010-12-26 21:17         ` ehem+grub
2010-12-26 21:55         ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-12-29  6:25           ` ehem+grub
2010-12-29  8:21             ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-12-30  7:11               ` ehem+grub
2010-12-29 19:54           ` Brendan Trotter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D171BBC.9000506@gmail.com \
    --to=phcoder@gmail.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.