From: Rainer Weikusat on
Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups(a)NTLWorld.COM>
writes:
>>
>>>>>
>>>>> Because your signal handler is broken.
>>>>>
>> An implementation might be 'broken' if [...]
>>
> M. Schwartz didn't say that the implementation of the C language was
> broken.

And you didn't read my text.

From: Rainer Weikusat on
David Schwartz <davids(a)webmaster.com> writes:
> On Feb 10, 8:02�am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote:
>
>> Consequently, the C-standard 'imposes no requirements' upon the
>> behaviour of a conforming implementation when encountering a signal
>> handler which assigns a value to an int. And that's the end of the
>> story insofar the C-standard is concerned, which is, after all,
>> supposed to standardize (some aspects of) C implementations and not
>> programs written in C. An implementation might be 'broken' if it is
>> claimed that it would adhere to the C-standard but doesn't, but code
>> which produces "output dependent on any unspecified, undefined, or
>> implementation-defined behavior" is just "not maximally portable
>> among conforming implementations".
>
> All true, and none of which contradicts *anything* I said.
>
> *His* signal handler is broken, and it is broken *because* it breaks
> this rule. That is what I said. And that is true.

This is not true. The code exploits implementation-specific behaviour
not defined by the C-standard and hence, it is not 'strictly
conforming'. Since it is acceptable to a conforming implementation, it
is 'conforming C'. The C-standard calls this (as quoted above) 'not
maximally portable among conforming implementations' and that's
something rather different from 'broken'.
From: David Schwartz on
On Feb 11, 2:39 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote:

> > *His* signal handler is broken, and it is broken *because* it breaks
> > this rule. That is what I said. And that is true.

> This is not true. The code exploits implementation-specific behaviour
> not defined by the C-standard and hence, it is not 'strictly
> conforming'. Since it is acceptable to a conforming implementation, it
> is 'conforming C'. The C-standard calls this (as quoted above) 'not
> maximally portable among conforming implementations' and that's
> something rather different from 'broken'.

Again, all true, and none of which contradicts what I said.

His code is broken. It is broken because it violates this rule.

You have come with yet another way in which it is not broken, and I
agree, it is not broken every possible way. It is not even broken
every possible way it could be broken because of violating this rule.

And if he modified his code to comply with this rule, it would work
the way he intended. As it is, it doesn't work on his platform
specifically because it violates this rule.

DS
From: Rainer Weikusat on
David Schwartz <davids(a)webmaster.com> writes:
> On Feb 11, 2:39�am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote:
>
>> > *His* signal handler is broken, and it is broken *because* it breaks
>> > this rule. That is what I said. And that is true.
>
>> This is not true. The code exploits implementation-specific behaviour
>> not defined by the C-standard and hence, it is not 'strictly
>> conforming'. Since it is acceptable to a conforming implementation, it
>> is 'conforming C'. The C-standard calls this (as quoted above) 'not
>> maximally portable among conforming implementations' and that's
>> something rather different from 'broken'.
>
> Again, all true, and none of which contradicts what I said.

It has so far contradicted your "this code is broken" statement each
and every time. The code is not "broken" just because it isn't
'strictly conforming C'. That's a misinterpretation of the C-standard
certain people like to spread.

[...]

> And if he modified his code to comply with this rule, it would work
> the way he intended. As it is, it doesn't work on his platform
> specifically because it violates this rule.

It didn't work on 'his platform' (which, for practical purposes, is
equivalent to all platforms glibc was ever ported to and all POSIX
systems the glibc maintainer(s) had ever heard of) because of the
missing volatile and this didn't "invoke the wrath of the gods"
because of some random statement about signal handlers in the
C-standard but specifically allowed the compiler to assume that one
read of the value stored in the object would be as good as twenty
reads, provided that no code modifying the object was possibly
reachable by 'ordinary' control flow (as in while (RUN);). The purpose
of volatile is to assert that "it is not so" in such cases. Reading
the value in the object should be considered to cause 'necessary side
effects' to happen and hence, when the code say 'if (RUN == 0);' twenty
times in a row, the content of the memory location the object resides
at is to be checked each time.

Since glibc does

typedef int sig_atomic_t

sig_atomic_t is an *A*L*I*A*S* for int on this platform and one can
always be used in place of the other.
From: David Schwartz on
On Feb 11, 7:20 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote:

> > Again, all true, and none of which contradicts what I said.

> It has so far contradicted your "this code is broken" statement each
> and every time.

No, you haven't. You've simply made an argument I didn't make and then
showed that argument to be incorrect.

> The code is not "broken" just because it isn't
> 'strictly conforming C'.

I agree.

> That's a misinterpretation of the C-standard
> certain people like to spread.

Perhaps.

> > And if he modified his code to comply with this rule, it would work
> > the way he intended. As it is, it doesn't work on his platform
> > specifically because it violates this rule.

> It didn't work on 'his platform' (which, for practical purposes, is
> equivalent to all platforms glibc was ever ported to and all POSIX
> systems the glibc maintainer(s) had ever heard of) because of the
> missing volatile and this didn't "invoke the wrath of the gods"
> because of some random statement about signal handlers in the
> C-standard but specifically allowed the compiler to assume that one
> read of the value stored in the object would be as good as twenty
> reads, provided that no code modifying the object was possibly
> reachable by 'ordinary' control flow (as in while (RUN);). The purpose
> of volatile is to assert that "it is not so" in such cases. Reading
> the value in the object should be considered to cause 'necessary side
> effects' to happen and hence, when the code say 'if (RUN == 0);' twenty
> times in a row, the content of the memory location the object resides
> at is to be checked each time.

True, but the whole reason for standards is so that people don't have
to worry about what optimizations different compilers might do or not
do.

> Since glibc does
>
>         typedef int sig_atomic_t
>
> sig_atomic_t is an *A*L*I*A*S* for int on this platform and one can
> always be used in place of the other.

So what? What does that have to do with what I said? I never said
there was no way he could write his code such that it would still
violate that part of the standard and not be broken. I said that:

1) His code is broken.

2) It is broken because it violates that section of the standard.

I did not say "all code that violates that section of the standard is
broken". I said *his* code is broken *because* it violates that part
of the standard.

You are quite correct that he could fix his code while still having it
violate that section of the standard. But I never denied that.

DS