Linux kernel, possible useless continue - Linux

This is a discussion on Linux kernel, possible useless continue - Linux ; 2.6.20, arch/i386/mm/init.c Below code I am curious in (A)'s continue will bring flow to (B) but from (B) to (A) no code updates the value of both pfn and max_low_pfn. So the condition of 'if' will always true. Is it ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: Linux kernel, possible useless continue

  1. Linux kernel, possible useless continue

    2.6.20, arch/i386/mm/init.c

    Below code I am curious in (A)'s continue will bring flow to (B) but
    from (B) to (A) no code updates the value of both pfn and max_low_pfn.
    So the condition of 'if' will always true. Is it useless?

    static void __init kernel_physical_mapping_init(pgd_t *pgd_base)
    {
    unsigned long pfn;
    pgd_t *pgd;
    pmd_t *pmd;
    pte_t *pte;
    int pgd_idx, pmd_idx, pte_ofs;

    pgd_idx = pgd_index(PAGE_OFFSET);
    pgd = pgd_base + pgd_idx;
    pfn = 0;

    (B) for (; pgd_idx < PTRS_PER_PGD; pgd++, pgd_idx++) {
    pmd = one_md_table_init(pgd);
    if (pfn >= max_low_pfn)
    (A) continue;
    for (pmd_idx = 0; pmd_idx < PTRS_PER_PMD && pfn < max_low_pfn; pmd+
    +, pmd_idx++) {
    unsigned int address = pfn * PAGE_SIZE + PAGE_OFFSET;

    /* Map with big pages if possible, otherwise create normal page
    tables. */
    if (cpu_has_pse) {
    unsigned int address2 = (pfn + PTRS_PER_PTE - 1) * PAGE_SIZE +
    PAGE_OFFSET + PAGE_SIZE-1;

    if (is_kernel_text(address) || is_kernel_text(address2))
    set_pmd(pmd, pfn_pmd(pfn, PAGE_KERNEL_LARGE_EXEC));
    else
    set_pmd(pmd, pfn_pmd(pfn, PAGE_KERNEL_LARGE));
    pfn += PTRS_PER_PTE;
    } else {
    pte = one_page_table_init(pmd);

    for (pte_ofs = 0; pte_ofs < PTRS_PER_PTE && pfn < max_low_pfn; pte+
    +, pfn++, pte_ofs++) {
    if (is_kernel_text(address))
    set_pte(pte, pfn_pte(pfn, PAGE_KERNEL_EXEC));
    else
    set_pte(pte, pfn_pte(pfn, PAGE_KERNEL));
    }
    }
    }
    }
    }


  2. Re: Linux kernel, possible useless continue

    Bin Chen wrote:

    > 2.6.20, arch/i386/mm/init.c
    >
    > Below code I am curious in (A)'s continue will bring flow to (B) but
    > from (B) to (A) no code updates the value of both pfn and max_low_pfn.
    > So the condition of 'if' will always true. Is it useless?


    Not completely, it skips the remainder of the loop, but the call to
    one_md_table_init still gets executed.

    It just avoids another indentation level, otherwise it's equivalent
    to

    if (pfn < max_low_pfn) {
    rest_of_the_loop
    }

    Kind regards,

    Iwo


  3. Re: Linux kernel, possible useless continue

    Bin Chen wrote:
    > Below code I am curious in (A)'s continue will bring flow to (B) but
    > from (B) to (A) no code updates the value of both pfn and max_low_pfn.
    > So the condition of 'if' will always true. Is it useless?


    Yes it is useless.

    > (B) for (; pgd_idx < PTRS_PER_PGD; pgd++, pgd_idx++) {
    > pmd = one_md_table_init(pgd);
    > if (pfn >= max_low_pfn)
    > (A) continue;
    > for (pmd_idx = 0;
    > pmd_idx < PTRS_PER_PMD && pfn < max_low_pfn;
    > pmd++, pmd_idx++) {

    [...]
    > }
    > }


    The if-comparison before (A) is the same as the second predicate for the
    loop. The only thing this does additionally is set pmd_idx to zero, but if
    that code relied on this side-effect of a loop variable it is broken
    anyways and either needs to be rewritten or accurately documented.
    However, it doesn't. Question is if the comparison in the loop is better
    removed (i.e. if the comparison's outcome could change with an inner
    iteration) or the outer.

    Other than that, Iwo Mergler's comment that one_md_table_init() is called
    with the next index indeed applies, and since max_low_pfn is not a local
    variable to that function it could indeed be modified.


    Uli


  4. Re: Linux kernel, possible useless continue

    Ulrich Eckhardt writes:
    > Bin Chen wrote:
    >> Below code I am curious in (A)'s continue will bring flow to (B) but
    >> from (B) to (A) no code updates the value of both pfn and max_low_pfn.
    >> So the condition of 'if' will always true. Is it useless?

    >
    > Yes it is useless.


    It is not, see below.

    >
    >> (B) for (; pgd_idx < PTRS_PER_PGD; pgd++, pgd_idx++) {
    >> pmd = one_md_table_init(pgd);
    >> if (pfn >= max_low_pfn)
    >> (A) continue;


    [...]

    > Other than that, Iwo Mergler's comment that one_md_table_init() is called
    > with the next index indeed applies,


    And this routine is documented by the following comment (and the code,
    of course):

    /*
    * Creates a middle page table and puts a pointer to it in the
    * given global directory entry. This only returns the gd entry
    * in non-PAE compilation mode, since the middle layer is folded.
    */

    Which means that the loop in questions populates all of the pmd (if a
    pmd is in use) and maps at most max_low_pfn pages of memory directly
    for use by the kernel.

  5. Re: Linux kernel, possible useless continue

    Rainer Weikusat wrote:
    > Ulrich Eckhardt writes:
    >> Bin Chen wrote:
    >>> Below code I am curious in (A)'s continue will bring flow to (B) but
    >>> from (B) to (A) no code updates the value of both pfn and max_low_pfn.
    >>> So the condition of 'if' will always true. Is it useless?

    >>
    >> Yes it is useless.

    >
    > It is not, see below.


    I'm not convinced yet, let's get this cleared up.

    >>
    >>> (B) for (; pgd_idx < PTRS_PER_PGD; pgd++, pgd_idx++) {
    >>> pmd = one_md_table_init(pgd);
    >>> if (pfn >= max_low_pfn)
    >>> (A) continue;


    You removed an important part here, the inner loop:
    > for (pmd_idx = 0;
    > pmd_idx < PTRS_PER_PMD && pfn < max_low_pfn;

    ^^^^^^^^^^^^^^^^^
    > pmd++, pmd_idx++) {


    The requirement 'pfn >= max_low_pfn' for the continue is the opposite of
    the one used in the loop, 'pfn < max_low_pfn'. So, if the first comparison
    is true, the continue skips the inner loop, because it's all that is left
    in the outer loop. If it didn't exist, the loop would only execute
    its 'pmd_idx=0' statement, and then terminate because
    the 'pfn
    Just in case it wasn't clear, the if clause is indeed useless, but not for
    the reasons that the OP suggested.


    Uli


  6. Re: Linux kernel, possible useless continue

    Ulrich Eckhardt writes:
    > Rainer Weikusat wrote:
    >> Ulrich Eckhardt writes:
    >>> Bin Chen wrote:
    >>>> Below code I am curious in (A)'s continue will bring flow to (B) but
    >>>> from (B) to (A) no code updates the value of both pfn and max_low_pfn.
    >>>> So the condition of 'if' will always true. Is it useless?
    >>>
    >>> Yes it is useless.

    >>
    >> It is not, see below.

    >
    > I'm not convinced yet, let's get this cleared up.
    >
    >>>
    >>>> (B) for (; pgd_idx < PTRS_PER_PGD; pgd++, pgd_idx++) {
    >>>> pmd = one_md_table_init(pgd);
    >>>> if (pfn >= max_low_pfn)
    >>>> (A) continue;

    >
    > You removed an important part here, the inner loop:
    >> for (pmd_idx = 0;
    >> pmd_idx < PTRS_PER_PMD && pfn < max_low_pfn;

    > ^^^^^^^^^^^^^^^^^
    >> pmd++, pmd_idx++) {

    >
    > The requirement 'pfn >= max_low_pfn' for the continue is the opposite of
    > the one used in the loop, 'pfn < max_low_pfn'. So, if the first comparison
    > is true, the continue skips the inner loop, because it's all that is left
    > in the outer loop.


    Exactly. The outer loop loops over all entries in the top-level page
    directory. It calls 'one_md_table_init' for each one, thereby
    populating all 'page middle directory' tables, insofar a pmd is
    actually used (when doing PAE). Additionally, it contains another loop
    which maps the first 'max_low_pfn' pages into the 'active' address
    space. After max_low_pfn pages have been mapped, the second loop shouldn't
    run anymore, but the remaining pmds should still get populated. Hence
    the continue, which skips over the inner loop after the pmd associated
    with the current values of pgd has been initialized.

  7. Re: Linux kernel, possible useless continue

    Rainer Weikusat writes:

    [...]

    > Exactly. The outer loop loops over all entries in the top-level page
    > directory. It calls 'one_md_table_init' for each one, thereby
    > populating all 'page middle directory' tables,


    That should be 'entires', not tables. The relevant two lines are below
    (from one_md_table_init)

    /* allocate a pmd */
    pmd_table = (pmd_t *) alloc_bootmem_low_pages(PAGE_SIZE);

    /* store its address into the associated pgd slot */
    set_pgd(pgd, __pgd(__pa(pmd_table) | _PAGE_PRESENT));

    (comments added by me).

    And these two lines of code a executed on each itertation of the
    'outer' loop in the routine in question if PAE is in use.

  8. Re: Linux kernel, possible useless continue

    Ulrich Eckhardt wrote:

    > Bin Chen wrote:
    >> Below code I am curious in (A)'s continue will bring flow to (B) but
    >> from (B) to (A) no code updates the value of both pfn and max_low_pfn.
    >> So the condition of 'if' will always true. Is it useless?

    >
    > Yes it is useless.
    >
    >> (B) for (; pgd_idx < PTRS_PER_PGD; pgd++, pgd_idx++) {
    >> pmd = one_md_table_init(pgd);
    >> if (pfn >= max_low_pfn)
    >> (A) continue;
    >> for (pmd_idx = 0;
    >> pmd_idx < PTRS_PER_PMD && pfn < max_low_pfn;
    >> pmd++, pmd_idx++) {

    > [...]
    >> }
    >> }

    >
    > The if-comparison before (A) is the same as the second predicate for the
    > loop. The only thing this does additionally is set pmd_idx to zero, but if
    > that code relied on this side-effect of a loop variable it is broken
    > anyways and either needs to be rewritten or accurately documented.
    > However, it doesn't. Question is if the comparison in the loop is better
    > removed (i.e. if the comparison's outcome could change with an inner
    > iteration) or the outer.
    >
    > Other than that, Iwo Mergler's comment that one_md_table_init() is called
    > with the next index indeed applies, and since max_low_pfn is not a local
    > variable to that function it could indeed be modified.
    >


    It's not quite what I meant.

    The original code:

    > static void __init kernel_physical_mapping_init(pgd_t *pgd_base)
    > {
    > unsigned long pfn;
    > pgd_t *pgd;
    > pmd_t *pmd;
    > pte_t *pte;
    > int pgd_idx, pmd_idx, pte_ofs;
    >
    > pgd_idx = pgd_index(PAGE_OFFSET);
    > pgd = pgd_base + pgd_idx;
    > pfn = 0;
    >
    > for (; pgd_idx < PTRS_PER_PGD; pgd++, pgd_idx++) {
    > pmd = one_md_table_init(pgd);
    > if (pfn >= max_low_pfn)
    > continue;
    >
    > /* Some code which modifies pfn */
    > }
    > }


    is equivalent to this:

    > static void __init kernel_physical_mapping_init(pgd_t *pgd_base)
    > {
    > unsigned long pfn;
    > pgd_t *pgd;
    > pmd_t *pmd;
    > pte_t *pte;
    > int pgd_idx, pmd_idx, pte_ofs;
    >
    > pgd_idx = pgd_index(PAGE_OFFSET);
    > pgd = pgd_base + pgd_idx;
    > pfn = 0;
    >
    > for (; pgd_idx < PTRS_PER_PGD; pgd++, pgd_idx++) {
    > pmd = one_md_table_init(pgd);
    >
    > if (pfn < max_low_pfn)
    > {
    > /* Some code which modifies pfn */
    > }
    > }
    > }


    Would you object to the second version?

    All it does is to save an additional level of indentation
    and thus making the code more readable IMHO.

    Rainer said it - the code populates all page entries (with
    one_md_table_init()), but only maps the ones below max_low_pfn
    into kernel space. As soon as pfn exceeds that limit, the loop
    reverts to only calling one_md_table_init().

    Kind regards,

    Iwo


  9. Re: Linux kernel, possible useless continue

    Iwo Mergler writes:

    [...]

    >> pgd_idx = pgd_index(PAGE_OFFSET);
    >> pgd = pgd_base + pgd_idx;
    >> pfn = 0;
    >>
    >> for (; pgd_idx < PTRS_PER_PGD; pgd++, pgd_idx++) {
    >> pmd = one_md_table_init(pgd);
    >> if (pfn >= max_low_pfn)
    >> continue;
    >>
    >> /* Some code which modifies pfn */
    >> }
    >> }

    [ ../arch/i386/mm/init.c ]

    [...]

    > All it does is to save an additional level of indentation
    > and thus making the code more readable IMHO.


    A better way to express this would be (IMO more readable and probably
    slightly faster):

    pgd = pgd_base + pgd_index(PAGE_OFFSET);
    pgd_end = pgd_base + PTRS_PER_PGD;
    pfn = 0;
    do {
    pmd = one_md_table_init(pgd);
    pmd_end = pmd + PTRS_PER_PMD;
    do {
    /* pte_t init code */
    } while (pfn < max_low_pfn && ++pmd < pmd_end);
    } while (++pgd < pgd_end && pfn < max_low_pfn);

    while (pgd < pgd_end) one_md_table_init(pgd++);

    OTOH, that would trigger several political correctness alerts ...


  10. Re: Linux kernel, possible useless continue

    Iwo Mergler wrote:
    > The original code:
    >
    >> static void __init kernel_physical_mapping_init(pgd_t *pgd_base)
    >> {
    >> unsigned long pfn;
    >> pgd_t *pgd;
    >> pmd_t *pmd;
    >> pte_t *pte;
    >> int pgd_idx, pmd_idx, pte_ofs;
    >>
    >> pgd_idx = pgd_index(PAGE_OFFSET);
    >> pgd = pgd_base + pgd_idx;
    >> pfn = 0;
    >>
    >> for (; pgd_idx < PTRS_PER_PGD; pgd++, pgd_idx++) {
    >> pmd = one_md_table_init(pgd);
    >> if (pfn >= max_low_pfn)
    >> continue;
    >>
    >> /* Some code which modifies pfn */
    >> }
    >> }

    >
    > is equivalent to this:
    >
    >> static void __init kernel_physical_mapping_init(pgd_t *pgd_base)
    >> {
    >> unsigned long pfn;
    >> pgd_t *pgd;
    >> pmd_t *pmd;
    >> pte_t *pte;
    >> int pgd_idx, pmd_idx, pte_ofs;
    >>
    >> pgd_idx = pgd_index(PAGE_OFFSET);
    >> pgd = pgd_base + pgd_idx;
    >> pfn = 0;
    >>
    >> for (; pgd_idx < PTRS_PER_PGD; pgd++, pgd_idx++) {
    >> pmd = one_md_table_init(pgd);
    >>
    >> if (pfn < max_low_pfn)
    >> {
    >> /* Some code which modifies pfn */
    >> }
    >> }
    >> }

    >
    > Would you object to the second version?


    No, I agree that they are equivalent.

    > All it does is to save an additional level of indentation
    > and thus making the code more readable IMHO.


    I have a third version, how about this one:

    for(...)
    if(x)
    continue;
    if(!x)
    for(...)
    ..

    Obviously, this is equivalent but plain stupid. One check is completely
    redundant. My point is that this very check is present as part of the for
    loop and as requirement for the continue. So, the above is really rather
    like this:

    for(...)
    if(x)
    continue;
    for(..; .. && !x; ..)
    ..

    The only difference is the initialisation statement in the inner loop, and
    for the case we're talking about this small difference doesn't make a
    difference overall, in particular not when it is compiled with a
    halfway-decent optimiser.

    > Rainer said it - the code populates all page entries (with
    > one_md_table_init()), but only maps the ones below max_low_pfn
    > into kernel space. As soon as pfn exceeds that limit, the loop
    > reverts to only calling one_md_table_init().


    I pretty much don't care what the code does for the application logic, and
    to be honest, I don't even understand it. The only thing that strikes me
    is that the same condition is checked twice, in a way that could be merged
    into one.

    Uli


  11. Re: Linux kernel, possible useless continue

    Ulrich Eckhardt writes:

    [...]

    > for(...)
    > if(x)
    > continue;
    > for(..; .. && !x; ..)
    > ..
    >
    > The only difference is the initialisation statement in the inner loop, and
    > for the case we're talking about this small difference doesn't make a
    > difference overall, in particular not when it is compiled with a
    > halfway-decent optimiser.


    As I understood the original question, it was about code semantics and
    not about hypothetical, accidental properties of unknown machine code
    generated by a random compiler for an arbitrary architecture. And
    wasn't "established theory" that one should rather not code to the
    idiosynkrasies of some translation or execution environment, but
    instead try to express the intent of the code clearly and leave 'the
    gory details' exactly to the compiler?

  12. Re: Linux kernel, possible useless continue

    On Mar 20, 2:03 am, Rainer Weikusat wrote:
    > Iwo Mergler writes:
    >
    > [...]
    >
    > >> pgd_idx = pgd_index(PAGE_OFFSET);
    > >> pgd = pgd_base + pgd_idx;
    > >> pfn = 0;

    >
    > >> for (; pgd_idx < PTRS_PER_PGD; pgd++, pgd_idx++) {
    > >> pmd = one_md_table_init(pgd);
    > >> if (pfn >= max_low_pfn)
    > >> continue;

    >
    > >> /* Some code which modifies pfn */
    > >> }
    > >> }

    >
    > [ ../arch/i386/mm/init.c ]
    >
    > [...]
    >
    > > All it does is to save an additional level of indentation
    > > and thus making the code more readable IMHO.

    >
    > A better way to express this would be (IMO more readable and probably
    > slightly faster):
    >
    > pgd = pgd_base + pgd_index(PAGE_OFFSET);
    > pgd_end = pgd_base + PTRS_PER_PGD;
    > pfn = 0;
    > do {
    > pmd = one_md_table_init(pgd);
    > pmd_end = pmd + PTRS_PER_PMD;
    > do {
    > /* pte_t init code */
    > } while (pfn < max_low_pfn && ++pmd < pmd_end);
    > } while (++pgd < pgd_end && pfn < max_low_pfn);
    >
    > while (pgd < pgd_end) one_md_table_init(pgd++);
    >
    > OTOH, that would trigger several political correctness alerts ...


    So in conclusion, the author's purpose is still to avoid another
    indention?


  13. Re: Linux kernel, possible useless continue

    "Bin Chen" writes:
    > Rainer Weikusat wrote:


    [...]

    >> pgd = pgd_base + pgd_index(PAGE_OFFSET);
    >> pgd_end = pgd_base + PTRS_PER_PGD;
    >> pfn = 0;
    >> do {
    >> pmd = one_md_table_init(pgd);
    >> pmd_end = pmd + PTRS_PER_PMD;
    >> do {
    >> /* pte_t init code */
    >> } while (pfn < max_low_pfn && ++pmd < pmd_end);
    >> } while (++pgd < pgd_end && pfn < max_low_pfn);
    >>
    >> while (pgd < pgd_end) one_md_table_init(pgd++);
    >>
    >> OTOH, that would trigger several political correctness alerts ...

    >
    > So in conclusion, the author's purpose is still to avoid another
    > indention?


    The author's intention was likely to express the algorithm given above
    with some accidental contortion (like incrementing pointers and
    counters or unifiying two 'semantically different' loops into one loop
    whose effective body changes at runtime).

    That you and the entity calling itself Ulrich Eckhardt apparently
    believe that a different algorithm would be translated into

    a) identical machine code
    b) identical machine code plus some superfluous instructions
    c) better machine code
    d) anything somebody else may come up with

    is not relevant at the source code level. That's why it is called
    _source code_, ie something supposed to contain a high-level
    description of what is supposed to happen, which a compiler can peruse
    to generate some machine code with (hopefully) the desired effect.

    Independently of your's and Mr Eckhardt's (unsubstantiated) beliefs
    about compilers, source code should not contain noise statements,
    because they will confuse an eventual reader.

    Always a nice quote in this respect:

    A program is a sort of publication. It's meant to be read by
    the programmer, another programmer (perhaps yourself a few
    days, weeks or years later), and lastly a machine. The
    machine doesn't care how pretty the program is - if the
    program compiles, the machine's happy - but people do, and
    they should.


  14. Re: Linux kernel, possible useless continue

    Rainer Weikusat wrote:
    > Ulrich Eckhardt writes:
    >
    > [...]
    >
    >> for(...)
    >> if(x)
    >> continue;
    >> for(..; .. && !x; ..)
    >> ..
    >>
    >> The only difference is the initialisation statement in the inner
    >> loop, and for the case we're talking about this small difference
    >> doesn't make a difference overall, in particular not when it is
    >> compiled with a halfway-decent optimiser.

    >
    > As I understood the original question, it was about code semantics and
    > not about hypothetical, accidental properties of unknown machine code
    > generated by a random compiler for an arbitrary architecture.


    The compiler that is able to digest Linux is not so random ...

    Seriously, fact remains that the initialisation is low-cost in any
    environment. Also, it might even be weighed up by the removal of the check
    for the continue and less instruction-cache use, but neither is important
    enough to merit any obfuscations in code and particularly not without
    profiling.

    What remains fact is that the if-clause with the continue can be removed
    without changing the behaviour of the code, or are you implying that that
    is not the case?

    > And wasn't "established theory" that one should rather not code to
    > the idiosynkrasies of some translation or execution environment, but
    > instead try to express the intent of the code clearly and leave 'the
    > gory details' exactly to the compiler?


    I'm not sure what you are implying with this. You are neither confirming
    nor denying my initial claim, instead you are attacking me with a
    straw-man argument.

    If you think I'm talking crap, say so at least and say why!

    Uli


  15. Re: Linux kernel, possible useless continue

    Ulrich Eckhardt writes:
    > Rainer Weikusat wrote:
    >> Ulrich Eckhardt writes:
    >>
    >> [...]
    >>
    >>> for(...)
    >>> if(x)
    >>> continue;
    >>> for(..; .. && !x; ..)
    >>> ..
    >>>
    >>> The only difference is the initialisation statement in the inner
    >>> loop, and for the case we're talking about this small difference
    >>> doesn't make a difference overall, in particular not when it is
    >>> compiled with a halfway-decent optimiser.

    >>
    >> As I understood the original question, it was about code semantics and
    >> not about hypothetical, accidental properties of unknown machine code
    >> generated by a random compiler for an arbitrary architecture.

    >
    > The compiler that is able to digest Linux is not so random ...


    It is at least a range of gcc releases.

    > Seriously, fact remains that the initialisation is low-cost in any
    > environment.


    This depends on the generated machine code (eg does it initialize a
    register or a memory location) and on the definition of 'low-cost'.

    > Also, it might even be weighed up by the removal of the check
    > for the continue and less instruction-cache use,


    This depends on the generated return code as well.

    > but neither is important enough to merit any obfuscations in code


    To me, the code is 'more obfuscated' if it contains more semantically
    useless things, which I have to understand to understand that they are
    semantically useless.

    [...]

    > What remains fact is that the if-clause with the continue can be removed
    > without changing the behaviour of the code,


    This may or may not be so, and depends on the generated machine code
    as well.

    >> And wasn't "established theory" that one should rather not code to
    >> the idiosynkrasies of some translation or execution environment, but
    >> instead try to express the intent of the code clearly and leave 'the
    >> gory details' exactly to the compiler?

    >
    > I'm not sure what you are implying with this.


    I am not implying anything. What you advocate would be a
    compiler version and translation algorithm dependant hack. That the
    hack is not intended to improve the generated code, only believed to
    not make it worse doesn't make it less of one. This is the stuff one
    may include in code if there is evidence that it actually improves
    something relevant, and even then, it should better be avoided.

  16. Re: Linux kernel, possible useless continue

    Rainer Weikusat wrote:
    > Independently of your's and Mr Eckhardt's (unsubstantiated) beliefs
    > about compilers, source code should not contain noise statements,
    > because they will confuse an eventual reader.


    Rainer Weikusat, since your discussion style is insulting and since you are
    spreading lies like the above about me, I'm out of this. I did a google
    search on you and it seems that this behaviour when challenged is typical
    for you, so there is little further I'm willing to do.

    > Always a nice quote in this respect:
    >
    > A program is a sort of publication. It's meant to be read by
    > the programmer, another programmer (perhaps yourself a few
    > days, weeks or years later), and lastly a machine. The
    > machine doesn't care how pretty the program is - if the
    > program compiles, the machine's happy - but people do, and
    > they should.
    >


    Another thing that doesn't even address anything in the posting you are
    answering to. While nothing in an of itself in this quote is IMHO wrong,
    nobody (well, at least not I) ever asked the question whether the
    discussed change should be made or not for reasons of clarity, this was a
    mere discussion about whether a statement was necessary. Nothing new in
    your arguing style, bashing people with unrelated statements...

    I was interested in opinions and in both learning and teaching something,
    but this is leading nowhere.

    Ulrich Eckhardt


  17. Re: Linux kernel, possible useless continue

    Ulrich Eckhardt writes:
    > Rainer Weikusat wrote:
    >> Independently of your's and Mr Eckhardt's (unsubstantiated) beliefs
    >> about compilers, source code should not contain noise statements,
    >> because they will confuse an eventual reader.

    >
    > Rainer Weikusat, since your discussion style is insulting and since you are
    > spreading lies like the above about me,


    Since the statement above is factually correct, which can be easily
    verified by reading the remaining thread, your claim is necessarily
    factually wrong.

    [...]

    >> Always a nice quote in this respect:
    >>
    >> A program is a sort of publication. It's meant to be read by
    >> the programmer, another programmer (perhaps yourself a few
    >> days, weeks or years later), and lastly a machine. The
    >> machine doesn't care how pretty the program is - if the
    >> program compiles, the machine's happy - but people do, and
    >> they should.
    >>

    >
    > Another thing that doesn't even address anything in the posting you are
    > answering to. While nothing in an of itself in this quote is IMHO
    > wrong, nobody (well, at least not I) ever asked the question whether the
    > discussed change should be made or not for reasons of clarity, this was a
    > mere discussion about whether a statement was necessary.


    As the subject of this posting quite clearly show, the question was
    wether it was 'useless', which is different from 'necessary'.

+ Reply to Thread