On Fri, 26 Mar 2010, SJS wrote:
> > > +#define RETRY( x ) do { \
> > > + x; \
> > > + } while (errno == EINTR);
> > >
>
> I was under the impression that good C style was to leave off the semicolons
> in macros, so that using the macro uses a semicolon like a normal statement.
> RETRY( src = fopen(srcFile, "rb") );
so be it.
> > Using this RETRY() macro is a bit ugly. I didn't like from the look
> > of it.
>
> Shouldn't there also be some sort of limit in the loop? If the
> function so wrapped manages to have a bug that results in it causing
> itself to be interrupted, this construct turns into an infinite loop.
i'm not following. why on earth would you want to hide a bug?
> RETRY_ON_EINTR seems like a better name. Still ugly, though.
it's ugly in it's original form, and you make it more ugly. good
strategy :) SINCE_EINTR_IS_NOT_FATAL_FOR_THIS_CODE_LOOP_IF_IT_HITS is
even less surprising...
to some extent i see your point, but i'm trying to reduce eye
bleeding, not add to it, and that sometimes means you have to look
things up. have you ever seriously thought about `_'? shall we replace
that with GETTEXT_OR_RAW_ARGUMENT? because that's what it does.
how's my macro called? RETRY. what does it do? retries. what? go look.
if it was instead randomly deleting your files, i would agree we have
a problem.
but, i'm willing^1 to bend in for this piece of code, taken directly
from glibc:
# define TEMP_FAILURE_RETRY(expression) \
(__extension__
\
({ long int __result;
\
do __result = (long int) (expression);
\
while (__result == -1L && errno == EINTR);
\
__result; }))
#endif
still think mine is ugly?
> > The old code didn't retry, why do you need it now?
>
> Are signals really causing problems? Ignoring a signal errors seems
> like a bad policy, especially when it's hidden in a macro.
this is not _ignoring_ it. this is _handling it_ by performing a
possible action: retrying the op.
ignoring is what the original code does.
[1]: not.
--
[-]
mkdir /nonexistent
--
To unsubscribe, send mail to [email protected].
