[issue11877] Change os.fsync() to support physical backing store syncs

[Steffen Daode Nurpmeso]

Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

On Sat,  7 May 2011 14:20:51 +0200, Charles-François Natali wrote:
> I really can't see a good reason for using it here (and
> anywhere, see http://c-faq.com/decl/auto.html).

You're right.

> Why are you using the "auto" storage class specifier? I know
> that "explicit is better than implicit"

Yup.  I'm doing what is happening for real in (x86) assembler.
Thus "auto" means (at a glance!) that this one will need space on
the stack.
(Conversely i'm not using "register" because who knows if that is
really true?  ;))

> Do you really need to use goto for such a simple code?

Yup.  Ok, this is more complicated.  The reason is that my funs
have exactly one entry point and exactly one place where they're
left.  This is because we here do manual instrumentalisation as in

ret
fun(args)
{
    locals
    s_NYD_ENTER;

    assertions

    ...

jleave:
    s_NYD_LEAVE;
    return;

[maybe only, if large: possibly "predict-false" code blocks]

[possible error jumps here
    goto jleave;]
}

We're prowd of that.  N(ot)Y(et)D(ead) is actually pretty cool,
i've used debuggers exactly 5 times in the past about ten years!
I don't even know exactly *how to use debuggers*.  8---} (NYD can
do backtracing, or, with NDEBUG and optional, profiling.)
A really good optimizing compiler will produce the very same code!
And i love nasm, but it's pretty non-portable.
But C is also nice.

But of course i can change this (in C) to simply use return, this
is easy here, no resources to be freed.

Thanks for looking at this, by the way.  :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________