Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #126772 > unrolled thread
| Started by | lee@ansync.com |
|---|---|
| First post | 2018-02-15 17:20 -0800 |
| Last post | 2018-02-26 10:17 -0800 |
| Articles | 20 on this page of 83 — 14 participants |
Back to article view | Back to comp.lang.c
Opinion sought: Is this strictly conforming C? lee@ansync.com - 2018-02-15 17:20 -0800
Re: Opinion sought: Is this strictly conforming C? James Kuyper <jameskuyper@verizon.net> - 2018-02-15 22:15 -0500
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-16 08:44 -0800
Re: Opinion sought: Is this strictly conforming C? jameskuyper@verizon.net - 2018-02-16 11:47 -0800
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-16 13:00 -0800
Re: Opinion sought: Is this strictly conforming C? Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-19 12:25 -0800
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-19 13:21 -0800
Re: Opinion sought: Is this strictly conforming C? Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2018-02-19 15:26 -0600
Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-02-19 13:59 -0800
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-19 14:38 -0800
Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-02-19 15:21 -0800
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-19 15:59 -0800
Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-02-19 17:11 -0800
Re: Opinion sought: Is this strictly conforming C? David Brown <david.brown@hesbynett.no> - 2018-02-20 09:17 +0100
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-20 07:58 -0800
Re: Opinion sought: Is this strictly conforming C? David Brown <david.brown@hesbynett.no> - 2018-02-20 18:21 +0100
Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-02-20 09:25 -0800
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-20 11:52 -0800
Re: Opinion sought: Is this strictly conforming C? Richard Damon <Richard@Damon-Family.org> - 2018-02-20 22:27 -0500
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-20 23:07 -0800
Re: Opinion sought: Is this strictly conforming C? Manfred <noname@invalid.add> - 2018-02-21 14:07 +0100
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-21 09:02 -0800
Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-02-21 09:50 -0800
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-21 12:46 -0800
Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-02-21 13:09 -0800
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-21 15:15 -0800
Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-02-21 15:51 -0800
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-21 17:06 -0800
Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-02-21 17:46 -0800
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-22 00:18 -0800
Re: Opinion sought: Is this strictly conforming C? Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 22:14 -0800
Re: Opinion sought: Is this strictly conforming C? Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 11:39 -0800
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-21 14:59 -0800
Re: Opinion sought: Is this strictly conforming C? Richard Damon <Richard@Damon-Family.org> - 2018-02-21 22:14 -0500
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-22 00:50 -0800
Re: Opinion sought: Is this strictly conforming C? Richard Damon <Richard@Damon-Family.org> - 2018-02-22 07:22 -0500
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-22 12:40 -0800
Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-02-22 13:00 -0800
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-22 13:48 -0800
Re: Opinion sought: Is this strictly conforming C? scott@slp53.sl.home (Scott Lurndal) - 2018-02-22 22:14 +0000
Re: Opinion sought: Is this strictly conforming C? Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 23:05 -0800
Re: Opinion sought: Is this strictly conforming C? Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 23:39 -0800
Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-02-22 10:39 -0800
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-22 13:20 -0800
Re: Opinion sought: Is this strictly conforming C? asetofsymbols@gmail.com - 2018-02-23 00:30 -0800
Re: Opinion sought: Is this strictly conforming C? Manfred <noname@invalid.add> - 2018-02-16 20:05 +0100
Re: Opinion sought: Is this strictly conforming C? lee@ansync.com - 2018-02-16 11:14 -0800
Re: Opinion sought: Is this strictly conforming C? Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-19 11:30 -0800
Re: Opinion sought: Is this strictly conforming C? Steve Carroll <frelwizzen@gmail.com> - 2018-03-01 09:01 -0800
Re: Opinion sought: Is this strictly conforming C? Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-19 11:08 -0800
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-19 17:16 -0800
Re: Opinion sought: Is this strictly conforming C? Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 23:16 -0800
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-22 00:25 -0800
Re: Opinion sought: Is this strictly conforming C? Richard Damon <Richard@Damon-Family.org> - 2018-02-22 07:41 -0500
Re: Opinion sought: Is this strictly conforming C? Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-24 13:24 -0800
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-25 12:07 -0800
Re: Opinion sought: Is this strictly conforming C? Richard Damon <Richard@Damon-Family.org> - 2018-02-25 18:34 -0500
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-26 08:21 -0800
Re: Opinion sought: Is this strictly conforming C? Richard Damon <Richard@Damon-Family.org> - 2018-02-26 22:22 -0500
Re: Opinion sought: Is this strictly conforming C? David Brown <david.brown@hesbynett.no> - 2018-02-27 09:16 +0100
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-27 08:48 -0800
Re: Opinion sought: Is this strictly conforming C? David Brown <david.brown@hesbynett.no> - 2018-02-28 10:24 +0100
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-28 09:03 -0800
Re: Opinion sought: Is this strictly conforming C? David Brown <david.brown@hesbynett.no> - 2018-02-28 22:31 +0100
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-28 15:19 -0800
Re: Opinion sought: Is this strictly conforming C? David Brown <david.brown@hesbynett.no> - 2018-03-01 12:37 +0100
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-03-01 11:03 -0800
Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-03-01 11:22 -0800
Re: Opinion sought: Is this strictly conforming C? Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 11:48 -0800
Re: Opinion sought: Is this strictly conforming C? Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 15:11 -0800
Re: Opinion sought: Is this strictly conforming C? Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 16:14 -0800
Re: Opinion sought: Is this strictly conforming C? Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 19:53 -0800
Re: Opinion sought: Is this strictly conforming C? Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 21:27 -0800
Re: Opinion sought: Is this strictly conforming C? Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 00:52 -0800
Re: Opinion sought: Is this strictly conforming C? Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 01:54 -0800
Re: Opinion sought: Is this strictly conforming C? Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 06:11 -0800
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-03-01 12:31 -0800
Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-03-01 13:15 -0800
Re: Opinion sought: Is this strictly conforming C? Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 14:55 -0800
Re: Opinion sought: Is this strictly conforming C? Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-03 02:19 -0800
Re: Opinion sought: Is this strictly conforming C? Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 03:03 -0800
Re: Opinion sought: Is this strictly conforming C? Keith Thompson <kst-u@mib.org> - 2018-02-25 15:36 -0800
Re: Opinion sought: Is this strictly conforming C? supercat@casperkitty.com - 2018-02-26 10:17 -0800
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-02-27 08:48 -0800 |
| Message-ID | <6c87947f-bcf1-49c1-a860-051ebd622d62@googlegroups.com> |
| In reply to | #127119 |
On Tuesday, February 27, 2018 at 2:16:45 AM UTC-6, David Brown wrote:
> On 27/02/18 04:22, Richard Damon wrote:
> > They clearly don't consider the standard to be what programmers should
> > expect from a compiler without using options, as they don't obey it in
> > that condition. They seem to expect that their users will realize they
> > have a powerful tool in their hands and will look at the instruction
> > manual before trying anything significant, but still, it does fairly
> > good at meeting the needs of the casual programmer out of the box.
>
> They also understand that programmers' needs and wants can differ, and
> provide options to define certain key types of behaviour that the
> standards don't define (access via incompatible pointer types and signed
> integer overflow behaviour being the obvious cases).
Some of my beefs with gcc are as follows:
1. The control isn't particularly fine-grained. A compiler which can avoid
applying an optimization in places where there is evidence that it might
cause behavior to differ from "literally translated C", while applying
the optimizations in places where there is no such evidence, will be
able to process low-level code much more efficiently than one which takes
an all-or-nothing approach.
2. The authors of gcc have taken the attitude that any program that relies
upon behaviors that aren't explicitly guaranteed should be considered
"broken", but its documentation fails to actually define all the behaviors
which gcc seems to be intended to provide. For example, gcc's
documentation states that it doesn't presently exploit c99's new
signed-left-shift freedoms for the purpose of optimization, but it does
not actually specify the behavior. Likewise with -fno-strict-aliasing.
3. The authors of gcc insist upon an interpretation of the Common Initial
Sequence rule which renders it essentially useless. In some measure
I blame the authors of the Standard for having refused to include a good
example:
struct s1 {int x; };
struct s2 {int x; };
union s1s2 {struct s1 v1; struct s2 v2;};
int fetch_s1_x(struct s1 *p)
{
// Note: complete definition of union s1s12 is visible here!
return p->x;
}
void store_s2_x(struct s2 *p, int v)
{
p->x=v;
}
int test(union s1s2 *up1, union s1s2 *up2)
{
if (fetch_s1_x(&up1->v1))
store_s2_x(&up2->v2,1);
return fetch_s1_x(&up1->v1);
}
The authors of gcc insist that the Common Initial Sequence only applies
to lvalue accesses made *directly through* lvalues of union type, even
though the Standard merely requires that the complete union type be
visible. It might be better to limit the CIS rule to cases where the
compiler could see that structure-types lvalues or pointers are derived
from pointers or lvalues if it bothered to look for such things, but
gcc essentially ignores the CIS rule altogether.
> It baffles me why certain people complain so much about the behaviour of
> gcc, when the gcc developers make such an effort to let users fine-tune
> exactly the behaviour they want. There are many different requirements
> out there - some people want a compiler that is stricter to the
> standards, others want helpful extensions, some want more optimisations
> while others want a "dumb translator". Some want to use constructs that
> many think are questionable but are legal C, others want an error
> message for them to catch mistakes. gcc (and clang) give you a myriad
> of options to let you use the compiler as /you/ want to use it - and
> then the moaners complain that it does not suit /their/ personal
> preferences by default, and that it has too many options!
> > Yes, reading documentation is VITAL to use a C compiler. Live with it.
>
> A lot of people forget that one.
Isn't one of the main purposes of having a portable language to allow
programmers to write code that others will be able to use on a variety of
implementations *without the original programmer having to know about all
the implementations in questions*?
If someone wants to write a program that only needs to work on C platforms
with certain relatively common features, but wants people to be able to
employ it on a wide range of general-purpose implementations for such
platforms, including those he knows nothing about, does it make sense to
limit the person to features and guarantees that would be supportable even
on the obscure platforms that have been obsolete for decades?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-02-28 10:24 +0100 |
| Message-ID | <p75sge$jt3$1@dont-email.me> |
| In reply to | #127135 |
On 27/02/18 17:48, supercat@casperkitty.com wrote:
> On Tuesday, February 27, 2018 at 2:16:45 AM UTC-6, David Brown wrote:
>> On 27/02/18 04:22, Richard Damon wrote:
>>> They clearly don't consider the standard to be what programmers should
>>> expect from a compiler without using options, as they don't obey it in
>>> that condition. They seem to expect that their users will realize they
>>> have a powerful tool in their hands and will look at the instruction
>>> manual before trying anything significant, but still, it does fairly
>>> good at meeting the needs of the casual programmer out of the box.
>>
>> They also understand that programmers' needs and wants can differ, and
>> provide options to define certain key types of behaviour that the
>> standards don't define (access via incompatible pointer types and signed
>> integer overflow behaviour being the obvious cases).
>
> Some of my beefs with gcc are as follows:
>
We have heard them before. They were mostly wrong then, and mostly
wrong now. And as always, they are mostly written in a way that is hard
to follow.
> 1. The control isn't particularly fine-grained. A compiler which can avoid
> applying an optimization in places where there is evidence that it might
> cause behavior to differ from "literally translated C", while applying
> the optimizations in places where there is no such evidence, will be
> able to process low-level code much more efficiently than one which takes
> an all-or-nothing approach.
Control in gcc is as fine-grained as you want. If you want to rely on
non-standard features for a particular part of your code, such as
faffing about with accessing via invalid types, you can have the flags
apply to just that part of your code. You can use pragmas and
function-specific optimisation flags. There are better, clearer, and
more reliable ways to handle it - but it's your choice.
And no, a different compiler would not be able to "process low-level
code /much/ more efficiently". No compiler, no optimisation levels, no
compilation strategy is always going to be the most efficient in all
cases - especially as "efficient" can mean different things to different
people, and to different target systems. But gcc does a fine job of
low-level code, and even if a different strategy could make some code a
little more efficient, it will not make it /much/ more efficient.
And /please/ don't take that as a cue to post another pointless
artificial function with a meaningless specification in an attempt to
prove your "point".
>
> 2. The authors of gcc have taken the attitude that any program that relies
> upon behaviors that aren't explicitly guaranteed should be considered
> "broken", but its documentation fails to actually define all the behaviors
> which gcc seems to be intended to provide. For example, gcc's
> documentation states that it doesn't presently exploit c99's new
> signed-left-shift freedoms for the purpose of optimization, but it does
> not actually specify the behavior. Likewise with -fno-strict-aliasing.
>
The authors of gcc take the attitude that if behaviour is defined in the
C standards, then it is defined in their compiler. If it is /not/
defined in the C standards (or other target-specific or OS-specific
standards), then they will sometimes give you a defined behaviour -
perhaps with a flag to control it. This is a /bonus/. Sure, they could
have given clearer documentation about some of their flags - but it is
better just to write code that doesn't need such non-C behaviour. Or
you can use the flags, making reasonable assumptions about how they work
(since the gcc developers are reasonable people), and test your code
thoroughly.
Anyway, who /cares/ about behaviour of signed integer shifts with
negative numbers, and other such cases? Use unsigned data when you need
to do bit manipulation.
> 3. The authors of gcc insist upon an interpretation of the Common Initial
> Sequence rule which renders it essentially useless. In some measure
> I blame the authors of the Standard for having refused to include a good
> example:
>
> struct s1 {int x; };
> struct s2 {int x; };
> union s1s2 {struct s1 v1; struct s2 v2;};
>
> int fetch_s1_x(struct s1 *p)
> {
> // Note: complete definition of union s1s12 is visible here!
> return p->x;
> }
> void store_s2_x(struct s2 *p, int v)
> {
> p->x=v;
> }
> int test(union s1s2 *up1, union s1s2 *up2)
> {
> if (fetch_s1_x(&up1->v1))
> store_s2_x(&up2->v2,1);
> return fetch_s1_x(&up1->v1);
> }
>
> The authors of gcc insist that the Common Initial Sequence only applies
> to lvalue accesses made *directly through* lvalues of union type, even
> though the Standard merely requires that the complete union type be
> visible. It might be better to limit the CIS rule to cases where the
> compiler could see that structure-types lvalues or pointers are derived
> from pointers or lvalues if it bothered to look for such things, but
> gcc essentially ignores the CIS rule altogether.
It might be even better if you simply don't write such daft code.
>
>> It baffles me why certain people complain so much about the behaviour of
>> gcc, when the gcc developers make such an effort to let users fine-tune
>> exactly the behaviour they want. There are many different requirements
>> out there - some people want a compiler that is stricter to the
>> standards, others want helpful extensions, some want more optimisations
>> while others want a "dumb translator". Some want to use constructs that
>> many think are questionable but are legal C, others want an error
>> message for them to catch mistakes. gcc (and clang) give you a myriad
>> of options to let you use the compiler as /you/ want to use it - and
>> then the moaners complain that it does not suit /their/ personal
>> preferences by default, and that it has too many options!
>
>>> Yes, reading documentation is VITAL to use a C compiler. Live with it.
>>
>> A lot of people forget that one.
>
> Isn't one of the main purposes of having a portable language to allow
> programmers to write code that others will be able to use on a variety of
> implementations *without the original programmer having to know about all
> the implementations in questions*?
Yes indeed. But you are not talking about writing in C, the
standardised portable language. You are talking about writing in weird
imaginary dialects of C based on what you think people wrote in books
long before the standards were written, and based on what you imagine
people to have intended to write (because you believe that the C
standards committee had clear plans in their head, but repeatedly wrote
something different in every version of the standards, while
telepathically transmitting the rules of "true C" to you alone).
If you want to use additional definitions beyond those given in standard
C, you have to read the documentation. If you want to use extra
compiler features to get particular effects not described in the
standard language, you need to read the documentation.
>
> If someone wants to write a program that only needs to work on C platforms
> with certain relatively common features, but wants people to be able to
> employ it on a wide range of general-purpose implementations for such
> platforms, including those he knows nothing about, does it make sense to
> limit the person to features and guarantees that would be supportable even
> on the obscure platforms that have been obsolete for decades?
>
Have you stopped beating your wife yet?
See, it is easy to ask misleading questions that can't be answered
simply without having false implications.
If you want to write portable C code, write portable C - don't write C
that relies on your imagined "relatively common" features. You can
write code that is quite widely portable by relying on features that
/are/ common - such as assuming "char" is 8-bit, "int" is 16-bit or
32-bit, that signed integers are two's complement, that floating point
is roughly IEEE compatible, and so on. But you need to base your
assumptions on reality, not your imagination about what you think C
should have been.
And since gcc is far and away the most common C compiler in use, on the
widest range of targets, then something can only be a "relatively common
feature" if it is implemented that way in gcc. Like it or not, gcc is
the nearest there is to a "de facto" implementation standard for C (and
C++, Fortran and Ada).
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-02-28 09:03 -0800 |
| Message-ID | <cf3e3d61-8a05-41a2-a8eb-14c7853e4604@googlegroups.com> |
| In reply to | #127156 |
On Wednesday, February 28, 2018 at 3:24:58 AM UTC-6, David Brown wrote:
> On 27/02/18 17:48, supercat@casperkitty.com wrote:
> > 2. The authors of gcc have taken the attitude that any program that relies
> > upon behaviors that aren't explicitly guaranteed should be considered
> > "broken", but its documentation fails to actually define all the behaviors
> > which gcc seems to be intended to provide. For example, gcc's
> > documentation states that it doesn't presently exploit c99's new
> > signed-left-shift freedoms for the purpose of optimization, but it does
> > not actually specify the behavior. Likewise with -fno-strict-aliasing.
> >
>
> The authors of gcc take the attitude that if behaviour is defined in the
> C standards, then it is defined in their compiler. If it is /not/
> defined in the C standards (or other target-specific or OS-specific
> standards), then they will sometimes give you a defined behaviour -
> perhaps with a flag to control it. This is a /bonus/. Sure, they could
> have given clearer documentation about some of their flags - but it is
> better just to write code that doesn't need such non-C behaviour. Or
> you can use the flags, making reasonable assumptions about how they work
> (since the gcc developers are reasonable people), and test your code
> thoroughly.
The documentation for gcc frequently goes out of its way to suggest that
certain actions would have defined behavior, at least when using certain
combinations of flags, but fails to actually say what the behavior actually
is. If the authors took the attitude that they'll avoid breaking any
constructs which documentation implies that gcc would support even if it
doesn't give a bullet-proof promise, such a distinction wouldn't matter.
But if the gcc's authors are going to insist that only things which are
actually guaranteed can be expected to work, that's less cool.
> Anyway, who /cares/ about behaviour of signed integer shifts with
> negative numbers, and other such cases? Use unsigned data when you need
> to do bit manipulation.
Anyone who has existing code which might use such things would care. My
bigger point is that this was a construct which was unambiguously defined
in useful fashion on every common platform. The definition was less than
ideal on some obscure platforms [none of which have ever, so far as I can
tell, received C99 implementations], but there was no plausible reason why
the behavior should not have remained the same on common platforms, save
only for the fact that it was simpler for the Standard to say that the
behavior is Undefined on all platforms, than to recognize a category of
platforms for which the Standard would describe the behavior, and a
category of (as it happens, non-existent) platforms for which it would not.
> > struct s1 {int x; };
> > struct s2 {int x; };
> > union s1s2 {struct s1 v1; struct s2 v2;};
> >
> > int fetch_s1_x(struct s1 *p)
> > {
> > // Note: complete definition of union s1s12 is visible here!
> > return p->x;
> > }
> > void store_s2_x(struct s2 *p, int v)
> > {
> > p->x=v;
> > }
> > int test(union s1s2 *up1, union s1s2 *up2)
> > {
> > if (fetch_s1_x(&up1->v1))
> > store_s2_x(&up2->v2,1);
> > return fetch_s1_x(&up1->v1);
> > }
> It might be even better if you simply don't write such daft code.
Most practical code would work "by happenstance" even with gcc. On the
other hand, a compiler which can't process the above code in accordance
with what the Standard actually says should not be trusted to reliably
process practical code either.
The only major use I can see for applying the address-of operator to a
union member would be to pass its address to code that is expecting to
use something that can be treated as that member type. The primary use
of the Common Initial Sequence rule is to allow for a variety of structures
that have certain features in common to be treated interchangeably in
parts of the code that only care about those features. I would hardly
regard those uses as "daft".
A dialect of C which did not allow for any storage that has ever been
accessed as any type to be accessed as any other would be useful for
some purposes, and I would actually favor such a dialect *if it were
recognized as being a subset of "normal" C*. It would be useless for
system programming in any situation where memory would need to be
recycled without malloc/free (which--remember--may not be available in
freestanding implementations).
On the other hand, perhaps the real problem lies with the fact that
6.5.7 relies upon a concept which might seem obvious, but which the
Standard fails to explicitly specify: if code uses one lvalue to
derive another and then accesses the latter, the latter access should
be considered an access to the original lvalue. If one allows for the
possibility of that access being spread out in time over other unrelated
operations, the rules about sequencing and overlapping access would then
be brought into play even if 6.5.7 were viewed only as describing cases
where the Standard would have to recognize accesses to the same object
via different ways, such as:
int x, *p=&x, *q=&x;
// The following two operations on x would "overlap" except that 6.5.7
// would allow them because they're the same type.
*p=1; *q=1;
If 6.5.7 were written to speak in terms of its representing an exception to
the overlapping-access rule (e.g. saying that if two pointers of the same
type, or differently-qualified versions of the same type, are derived from
the same object in the same way, operations using those pointers will be
sequenced relative to each other), rather than as imposing new requirements,
there would be no need for optimizers to care about the types of objects
Further, all one would need to do to make it possible for code to do
anything that would be possible under -fno-strict-aliasing to recognize a
syntax (perhaps something like a (thingType *volatile) cast) that would
indicate that the pointer should be regarded as though it might have been
derived from anything from which a pointer could have been derived, with
such derivation occurring at the time of the cast.
On the other hand, perhaps the reason that the Standard does not have
a specific rule that would allow an object of aggregate type to have its
stored value modified using an lvalue of aggregate's member type is that
the act of deriving a lvalue D of member type from an lvalue of aggregate
type A and then using that lvalue should actually be regarded as an
access to A using the original type, at least until something is done with
an lvalue that identifies A but is not derived from D.
> > Isn't one of the main purposes of having a portable language to allow
> > programmers to write code that others will be able to use on a variety of
> > implementations *without the original programmer having to know about all
> > the implementations in questions*?
>
> Yes indeed. But you are not talking about writing in C, the
> standardised portable language. You are talking about writing in weird
> imaginary dialects of C based on what you think people wrote in books
> long before the standards were written, and based on what you imagine
> people to have intended to write (because you believe that the C
> standards committee had clear plans in their head, but repeatedly wrote
> something different in every version of the standards, while
> telepathically transmitting the rules of "true C" to you alone).
What fraction of the tasks that can be performed using C can be performed
in practical fashion on 100% of the platforms that run C?
What fraction could be done practically on most such platforms, but not
100%?
I would judge the usefulness of a "portable" language as being strongly
related to the range of tasks that can be performed by code that targets
an open-ended set of implementations. Not necessarily all implementations,
but a set that isn't limited to particular ones a programmer knows about.
If the vast majority of platforms could support a behavioral guarantee but
5% cannot, should a programmer's choices be limited to:
1. Write code that does not rely upon that guarantee but runs slower
than code which could rely upon it, and have such code be usable
on an open-ended set of implementations, and refrain from even
trying to doing any tasks that can't be done practically without the
guarantee.
2. Write code that relies upon the guarantee, but is only usable on
those few implementations about which the programmer has particular
knowledge.
rather than:
3. Write code that relies upon the guarantee, and is usable on an
open-ended set of implementations which aren't running on the
platforms that can't support it.
I would suggest that #3 would be far superior to #1 and #2. To the extent
that the Standard accommodates #3, code should use the means therein
described to achieve it. In cases where the authors of the Standard fail
to provide features necessary to perform a task, however, I would suggest
that quality general-purpose compilers should attempt to do what they can
to support code that tries to do #3, regardless of whether the Standard
writers mandate it, because approach #3 is so far superior to #1 and #2.
> If you want to use additional definitions beyond those given in standard
> C, you have to read the documentation. If you want to use extra
> compiler features to get particular effects not described in the
> standard language, you need to read the documentation.
How should one read the documentation for compilers that one doesn't know
about, but with which people one doesn't know about might want to use
the code?
> And since gcc is far and away the most common C compiler in use, on the
> widest range of targets, then something can only be a "relatively common
> feature" if it is implemented that way in gcc. Like it or not, gcc is
> the nearest there is to a "de facto" implementation standard for C (and
> C++, Fortran and Ada).
With optimizations disabled, it is semantically decent but produces rather
inefficient code. It would be much more useful for many purposes if it
had options to enable some relatively simple and safe optimizations without
enabling more aggressive ones. Given that more aggressive optimizations
require complicated analysis that slows down build times, I'd suggest that
simpler optimizations would be in pretty much every way better except in
those parts of the code where the savings in execution time would outweigh
the increase in build time.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-02-28 22:31 +0100 |
| Message-ID | <p7773v$gbe$1@dont-email.me> |
| In reply to | #127160 |
On 28/02/18 18:03, supercat@casperkitty.com wrote:
> On Wednesday, February 28, 2018 at 3:24:58 AM UTC-6, David Brown wrote:
>> On 27/02/18 17:48, supercat@casperkitty.com wrote:
>>> 2. The authors of gcc have taken the attitude that any program that relies
>>> upon behaviors that aren't explicitly guaranteed should be considered
>>> "broken", but its documentation fails to actually define all the behaviors
>>> which gcc seems to be intended to provide. For example, gcc's
>>> documentation states that it doesn't presently exploit c99's new
>>> signed-left-shift freedoms for the purpose of optimization, but it does
>>> not actually specify the behavior. Likewise with -fno-strict-aliasing.
>>>
>>
>> The authors of gcc take the attitude that if behaviour is defined in the
>> C standards, then it is defined in their compiler. If it is /not/
>> defined in the C standards (or other target-specific or OS-specific
>> standards), then they will sometimes give you a defined behaviour -
>> perhaps with a flag to control it. This is a /bonus/. Sure, they could
>> have given clearer documentation about some of their flags - but it is
>> better just to write code that doesn't need such non-C behaviour. Or
>> you can use the flags, making reasonable assumptions about how they work
>> (since the gcc developers are reasonable people), and test your code
>> thoroughly.
>
> The documentation for gcc frequently goes out of its way to suggest that
> certain actions would have defined behavior, at least when using certain
> combinations of flags, but fails to actually say what the behavior actually
> is. If the authors took the attitude that they'll avoid breaking any
> constructs which documentation implies that gcc would support even if it
> doesn't give a bullet-proof promise, such a distinction wouldn't matter.
> But if the gcc's authors are going to insist that only things which are
> actually guaranteed can be expected to work, that's less cool.
Why don't you ask the gcc authors? They follow the mailing lists, and
try to be helpful. Of course, it would help if you ask in a concise and
polite manner.
>
>> Anyway, who /cares/ about behaviour of signed integer shifts with
>> negative numbers, and other such cases? Use unsigned data when you need
>> to do bit manipulation.
>
> Anyone who has existing code which might use such things would care.
People who used such code care mainly about it working on the particular
platform and compiler they are using. After all, the great majority of
C code is only ever compiled for a single target, using one compiler -
or at most within a small group of targets. Portable code is a minority
(an important minority, of course).
> My
> bigger point is that this was a construct which was unambiguously defined
> in useful fashion on every common platform.
No, it was never defined in any portable way. Some compilers might have
defined it in a particular way, but certainly nothing you could rely on
for different compilers or different targets.
> The definition was less than
> ideal on some obscure platforms [none of which have ever, so far as I can
> tell, received C99 implementations], but there was no plausible reason why
> the behavior should not have remained the same on common platforms, save
> only for the fact that it was simpler for the Standard to say that the
> behavior is Undefined on all platforms, than to recognize a category of
> platforms for which the Standard would describe the behavior, and a
> category of (as it happens, non-existent) platforms for which it would not.
There you go again - thinking that because /you/ can't think of a reason
for something, it must not be the case, or that the standards committee
thought intended something other than what they wrote. It does not
/matter/ what you think, or what "plausible reasons" you can imagine, or
fail to imagine. It does not /matter/ how you think C used to work, or
how you think some compilers work, or how you think some platforms work.
It does not /matter/ what platforms /you/ think are obscure or
outdated. It certainly does not matter what you think the Standards
committees "intended" or did not intend.
What matters is what the standards (the C standards, together with any
other /relevant/ standards or documents for the platform) /say/. And
when they say something has undefined behaviour, compilers are under no
obligation to give any definition to it. When the standards fail to
give a defined behaviour for something, the behaviour is again
undefined. It does not matter if this lack of definition is because of
some "obscure" platforms, for optimisation purposes, for compiler
simplicity, or an accidental omission in the text. It really is that
simple.
And whether you like it or not, a number of people on the C standards
committees have been compiler users or compiler writers for some
/really/ obscure platforms. The kind of devices with 18-bit chars, or
sizeof(int) == 3, or no stack.
>
>>> struct s1 {int x; };
>>> struct s2 {int x; };
>>> union s1s2 {struct s1 v1; struct s2 v2;};
>>>
>>> int fetch_s1_x(struct s1 *p)
>>> {
>>> // Note: complete definition of union s1s12 is visible here!
>>> return p->x;
>>> }
>>> void store_s2_x(struct s2 *p, int v)
>>> {
>>> p->x=v;
>>> }
>>> int test(union s1s2 *up1, union s1s2 *up2)
>>> {
>>> if (fetch_s1_x(&up1->v1))
>>> store_s2_x(&up2->v2,1);
>>> return fetch_s1_x(&up1->v1);
>>> }
>
>> It might be even better if you simply don't write such daft code.
>
> Most practical code would work "by happenstance" even with gcc. On the
> other hand, a compiler which can't process the above code in accordance
> with what the Standard actually says should not be trusted to reliably
> process practical code either.
Yes, clearly gcc is not a tool to rely on for compiling C. The whole of
the programming world should throw it out immediately.
<snip>
If you think that gcc is wrong, file a bug. Smarter minds than yours
will look at it and compare it to the standards, and see if the compiler
needs to be changed.
>
>>> Isn't one of the main purposes of having a portable language to allow
>>> programmers to write code that others will be able to use on a variety of
>>> implementations *without the original programmer having to know about all
>>> the implementations in questions*?
>>
>> Yes indeed. But you are not talking about writing in C, the
>> standardised portable language. You are talking about writing in weird
>> imaginary dialects of C based on what you think people wrote in books
>> long before the standards were written, and based on what you imagine
>> people to have intended to write (because you believe that the C
>> standards committee had clear plans in their head, but repeatedly wrote
>> something different in every version of the standards, while
>> telepathically transmitting the rules of "true C" to you alone).
>
> What fraction of the tasks that can be performed using C can be performed
> in practical fashion on 100% of the platforms that run C?
>
> What fraction could be done practically on most such platforms, but not
> 100%?
And what use would making up such numbers be?
<snip>
>
>> If you want to use additional definitions beyond those given in standard
>> C, you have to read the documentation. If you want to use extra
>> compiler features to get particular effects not described in the
>> standard language, you need to read the documentation.
>
> How should one read the documentation for compilers that one doesn't know
> about, but with which people one doesn't know about might want to use
> the code?
Read what you want. Then either write C code that works, or write
jumbled nonsense and blame the tools.
>
>> And since gcc is far and away the most common C compiler in use, on the
>> widest range of targets, then something can only be a "relatively common
>> feature" if it is implemented that way in gcc. Like it or not, gcc is
>> the nearest there is to a "de facto" implementation standard for C (and
>> C++, Fortran and Ada).
>
> With optimizations disabled, it is semantically decent but produces rather
> inefficient code. It would be much more useful for many purposes if it
> had options to enable some relatively simple and safe optimizations without
> enabling more aggressive ones. Given that more aggressive optimizations
> require complicated analysis that slows down build times, I'd suggest that
> simpler optimizations would be in pretty much every way better except in
> those parts of the code where the savings in execution time would outweigh
> the increase in build time.
>
And I'd suggest that if you spent a fraction of the time you waste on
your suggestions, assumptions, and nonsensical arguments on learning to
write C correctly, and learning to live with the tools that actually
exist, then you'd get on far better. Alternatively, if you don't like
the way gcc does something, then make the effort to change it.
Meanwhile, other people will successfully (for the most part) write
correct and efficient code using gcc and other compilers.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-02-28 15:19 -0800 |
| Message-ID | <2e01e61b-7db1-48c4-9f48-84f818708750@googlegroups.com> |
| In reply to | #127166 |
On Wednesday, February 28, 2018 at 3:32:02 PM UTC-6, David Brown wrote: > On 28/02/18 18:03, supercat@casperkitty.com wrote: > > On Wednesday, February 28, 2018 at 3:24:58 AM UTC-6, David Brown wrote: > >> Anyway, who /cares/ about behaviour of signed integer shifts with > >> negative numbers, and other such cases? Use unsigned data when you need > >> to do bit manipulation. > > > > Anyone who has existing code which might use such things would care. > > People who used such code care mainly about it working on the particular > platform and compiler they are using. After all, the great majority of > C code is only ever compiled for a single target, using one compiler - > or at most within a small group of targets. Portable code is a minority > (an important minority, of course). Most code performs tasks that would be practical on an open-ended set of platforms, but not on every imaginable platform. I would suggest that making such code portable among general-purpose implementations for platforms that can support it would be both practical and useful. The reason so little code is portable is that the Standard fails to provide means to accomplish many tasks in portable fashion. > > My > > bigger point is that this was a construct which was unambiguously defined > > in useful fashion on every common platform. > > No, it was never defined in any portable way. Some compilers might have > defined it in a particular way, but certainly nothing you could rely on > for different compilers or different targets. If an implementation uses two's-complement integers and neither signed nor unsigned types include padding bits, what latitude would C89 give it to process x<<1 as yielding anything other than x*2 in any case where the latter would be defined? If any of the bits that are common to signed and unsigned types weren't stored in the same places, that would violate the requirement that reading a positive signed value using a pointer of the corresponding unsigned type will yield that same value. If the uppermost value bit for an unsigned type without padding weren't the leftmost bit, that would violate the semantics for shifting unsigned types. Put those together and I really don't see any wiggle room at all on implementations meeting the aforementioned criteria. I'd have no objection to saying that left-shifting a negative number may yield UB on platforms where C89 didn't nail down the behavior, but such platforms are rare. Can you name any C99 platforms that would, by any plausible measure, represent even 1% of the marketplace? > > The definition was less than > > ideal on some obscure platforms [none of which have ever, so far as I can > > tell, received C99 implementations], but there was no plausible reason why > > the behavior should not have remained the same on common platforms, save > > only for the fact that it was simpler for the Standard to say that the > > behavior is Undefined on all platforms, than to recognize a category of > > platforms for which the Standard would describe the behavior, and a > > category of (as it happens, non-existent) platforms for which it would not. > > There you go again - thinking that because /you/ can't think of a reason > for something, it must not be the case, or that the standards committee > thought intended something other than what they wrote. It does not > /matter/ what you think, or what "plausible reasons" you can imagine, or > fail to imagine. It does not /matter/ how you think C used to work, or > how you think some compilers work, or how you think some platforms work. > It does not /matter/ what platforms /you/ think are obscure or > outdated. It certainly does not matter what you think the Standards > committees "intended" or did not intend. If a Committee were to act in sufficiently outrageous fashion, it would be right and proper for everyone to ignore any standard they might publish. People may differ with regard to what level of conduct should be viewed as "sufficiently outrageous", and may regard as infinitesimal the likelihood of the Committee acting in such fashion. Nonetheless, any authority the Committee may have should be predicated upon its acting at least somewhat reasonably. If the Committee decides to make a change which would break some existing code after they have weighed their options and determined that the advantages would outweigh the disadvantages, such action may be reasonable. If they intend to break existing code for no reason whatsoever, that would be far less reasonable. > What matters is what the standards (the C standards, together with any > other /relevant/ standards or documents for the platform) /say/. And > when they say something has undefined behaviour, compilers are under no > obligation to give any definition to it. When the standards fail to > give a defined behaviour for something, the behaviour is again > undefined. It does not matter if this lack of definition is because of > some "obscure" platforms, for optimisation purposes, for compiler > simplicity, or an accidental omission in the text. It really is that > simple. What matters, ultimately, is what compilers would need to do to process code in a fashion consistent with the purpose thereof. The authors of the Standard acknowledge that an implementation could be conforming and yet be totally useless, so I don't see how it can be reasonably regarded as the sole authority over what an implementation must do to be considered suitable for any particular purpose. > And whether you like it or not, a number of people on the C standards > committees have been compiler users or compiler writers for some > /really/ obscure platforms. The kind of devices with 18-bit chars, or > sizeof(int) == 3, or no stack. I've used some obscure platforms, and recognize that implementations that target such platforms should be expected to behave differently from those that target common platforms. I see no reason to pretend that there is nothing unusual or quirky about such implementations. Actually, I'd suggest that the usefulness of such implementations and code written for them would be enhanced by recognizing their differences, rather than simply having the Standard generally ignore any behaviors that aren't the same on 100% of platforms. > > Most practical code would work "by happenstance" even with gcc. On the > > other hand, a compiler which can't process the above code in accordance > > with what the Standard actually says should not be trusted to reliably > > process practical code either. > > Yes, clearly gcc is not a tool to rely on for compiling C. The whole of > the programming world should throw it out immediately. The -fno-strict-aliasing dialect is processed reliably. The -fstrict-aliasing dialect should not be trusted with code that may need the Effective Type of any object to change during its lifetime, even though the Standard requires compilers to support such code. The rules as written are unworkable unless a compiler is willing to forego what should be useful optimization opportunities; gcc could be both simpler and better if it had a non-conforming mode for use with programs that don't need to change objects' effective types and a less aggressive mode that was willing to forego optimizations in exchange for being able to handle all required cases easily. > If you think that gcc is wrong, file a bug. Smarter minds than yours > will look at it and compare it to the standards, and see if the compiler > needs to be changed. Some bugs have been filed, but the fundamental problem is that the Standard is only designed to allow for a certain level of optimization but the authors of gcc are trying to go beyond what the Standard is designed for, rather than offering a mode that is documented as non-conforming, but which could be very useful for certain kinds of programs. > >>> Isn't one of the main purposes of having a portable language to allow > >>> programmers to write code that others will be able to use on a variety of > >>> implementations *without the original programmer having to know about all > >>> the implementations in questions*? > >> > >> Yes indeed. But you are not talking about writing in C, the > >> standardised portable language. You are talking about writing in weird > >> imaginary dialects of C based on what you think people wrote in books > >> long before the standards were written, and based on what you imagine > >> people to have intended to write (because you believe that the C > >> standards committee had clear plans in their head, but repeatedly wrote > >> something different in every version of the standards, while > >> telepathically transmitting the rules of "true C" to you alone). > > > > What fraction of the tasks that can be performed using C can be performed > > in practical fashion on 100% of the platforms that run C? > > > > What fraction could be done practically on most such platforms, but not > > 100%? > > And what use would making up such numbers be? My point is that the former fraction is much smaller than the second. Which is more useful--being able to run a small number programs on every platform without modification, or being able to run a much larger number of programs on a wide range of platforms? > >> If you want to use additional definitions beyond those given in standard > >> C, you have to read the documentation. If you want to use extra > >> compiler features to get particular effects not described in the > >> standard language, you need to read the documentation. > > > > How should one read the documentation for compilers that one doesn't know > > about, but with which people one doesn't know about might want to use > > the code? > > Read what you want. Then either write C code that works, or write > jumbled nonsense and blame the tools. Or document the program's requirements in human-readable form rather than machine-readable form, and require that anyone seeking to use the code examine the compiler's human-readable documentation to figure out what if anything can be done to configure their tools appropriately. Not impossible, but more arduous and error-prone than would be required if the Standard allowed configuration requirements to be expressed in machine- readable source code. > > With optimizations disabled, it is semantically decent but produces rather > > inefficient code. It would be much more useful for many purposes if it > > had options to enable some relatively simple and safe optimizations without > > enabling more aggressive ones. Given that more aggressive optimizations > > require complicated analysis that slows down build times, I'd suggest that > > simpler optimizations would be in pretty much every way better except in > > those parts of the code where the savings in execution time would outweigh > > the increase in build time. > > And I'd suggest that if you spent a fraction of the time you waste on > your suggestions, assumptions, and nonsensical arguments on learning to > write C correctly, and learning to live with the tools that actually > exist, then you'd get on far better. Alternatively, if you don't like > the way gcc does something, then make the effort to change it. > > Meanwhile, other people will successfully (for the most part) write > correct and efficient code using gcc and other compilers. Or code which mostly works except for some corner cases where optimizations create exploitable security holes which would not have been exploitable absent said optimizations.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-01 12:37 +0100 |
| Message-ID | <p78omd$olo$1@dont-email.me> |
| In reply to | #127168 |
On 01/03/18 00:19, supercat@casperkitty.com wrote: > On Wednesday, February 28, 2018 at 3:32:02 PM UTC-6, David Brown wrote: >> On 28/02/18 18:03, supercat@casperkitty.com wrote: >>> On Wednesday, February 28, 2018 at 3:24:58 AM UTC-6, David Brown wrote: >>>> Anyway, who /cares/ about behaviour of signed integer shifts with >>>> negative numbers, and other such cases? Use unsigned data when you need >>>> to do bit manipulation. >>> >>> Anyone who has existing code which might use such things would care. >> >> People who used such code care mainly about it working on the particular >> platform and compiler they are using. After all, the great majority of >> C code is only ever compiled for a single target, using one compiler - >> or at most within a small group of targets. Portable code is a minority >> (an important minority, of course). > > Most code performs tasks that would be practical on an open-ended set > of platforms, but not on every imaginable platform. I would suggest that > making such code portable among general-purpose implementations for > platforms that can support it would be both practical and useful. The > reason so little code is portable is that the Standard fails to provide > means to accomplish many tasks in portable fashion. Stop "suggesting", and try thinking. Most code is written for a specific purpose. The programs written by companies in-house, or compiled and delivered as executables, far outweigh the code in libraries, or available as open source, or otherwise being widely portable. So for most code, portability is irrelevant. The code /might/ be portable to any C compiler and any target, or it /might/ be portable to a range of similar targets or compilers - or it might be tied tightly to one compiler or one target. In most cases, the programmer does not care. This has nothing to do with what the standards say or don't say - it is a matter of what professional programmers do for a living. > >>> My >>> bigger point is that this was a construct which was unambiguously defined >>> in useful fashion on every common platform. >> >> No, it was never defined in any portable way. Some compilers might have >> defined it in a particular way, but certainly nothing you could rely on >> for different compilers or different targets. > > If an implementation uses two's-complement integers and neither signed nor > unsigned types include padding bits, what latitude would C89 give it to > process x<<1 as yielding anything other than x*2 in any case where the > latter would be defined? C89 did not define what "left shifting" of a signed type means. You can make some guesses, based on other definitions and try to get a consistent picture. In particular, you can assume that if all values are valid and can be represented, then left-shifting an unsigned value as an unsigned type or a signed type should give the same result. That means "left shifting" must be in terms of logical bit value positions, rather than the bits in the underlying representation. But what happens when you left-shift a signed integer? There is no definition of what that might mean in the C89 standards - it is undefined behaviour, and can't even be guessed from other points. In particular, it is /not/ implementation-defined behaviour (which needs to be stated explicitly, as is the case for right-shifting negative numbers). The nearest you could guess is that it is an exceptional condition, and therefore undefined behaviour. C99 did not change anything here. The text clarified that left-shifting negative numbers is undefined behaviour. The C99 rationale backs this up - it does not mention the point, which it would have done if it had been a change. You can well say that left-shifting a negative number /should/ give x*2, at least on two's complement systems. Or you could say it /should/ be implementation-defined. But it is /not/ defined like that, and never has been. (And as always, implementations or other standards can give it a definition - it is merely undefined by the C standards.) > >>> The definition was less than >>> ideal on some obscure platforms [none of which have ever, so far as I can >>> tell, received C99 implementations], but there was no plausible reason why >>> the behavior should not have remained the same on common platforms, save >>> only for the fact that it was simpler for the Standard to say that the >>> behavior is Undefined on all platforms, than to recognize a category of >>> platforms for which the Standard would describe the behavior, and a >>> category of (as it happens, non-existent) platforms for which it would not. >> >> There you go again - thinking that because /you/ can't think of a reason >> for something, it must not be the case, or that the standards committee >> thought intended something other than what they wrote. It does not >> /matter/ what you think, or what "plausible reasons" you can imagine, or >> fail to imagine. It does not /matter/ how you think C used to work, or >> how you think some compilers work, or how you think some platforms work. >> It does not /matter/ what platforms /you/ think are obscure or >> outdated. It certainly does not matter what you think the Standards >> committees "intended" or did not intend. > > If a Committee were to act in sufficiently outrageous fashion, it would > be right and proper for everyone to ignore any standard they might publish. > People may differ with regard to what level of conduct should be viewed as > "sufficiently outrageous", and may regard as infinitesimal the likelihood of > the Committee acting in such fashion. Nonetheless, any authority the > Committee may have should be predicated upon its acting at least somewhat > reasonably. And most people - C programmers, and C compiler writers - agree that the committee is basically reasonable. Pretty much everyone has points in the standards that they would prefer to be defined differently, or at least explained differently. But the standards certainly work well enough that they are a useful standard. A few people - such as yourself - get hung up about minor little details that are irrelevant to most code, and easily avoided. If you are "outraged" by the inability to left-shift negative numbers safely, then I think you need to re-tune your "outrage" filters. > > If the Committee decides to make a change which would break some existing > code after they have weighed their options and determined that the advantages > would outweigh the disadvantages, such action may be reasonable. If they > intend to break existing code for no reason whatsoever, that would be far > less reasonable. The Committee didn't change anything here. And one of the prime functions of the Committee has always been to look at existing code and practices, and ensure that they /don't/ make breaking changes without extremely good reason. Most of the poor points about the C language stem precisely from that principle. > >> What matters is what the standards (the C standards, together with any >> other /relevant/ standards or documents for the platform) /say/. And >> when they say something has undefined behaviour, compilers are under no >> obligation to give any definition to it. When the standards fail to >> give a defined behaviour for something, the behaviour is again >> undefined. It does not matter if this lack of definition is because of >> some "obscure" platforms, for optimisation purposes, for compiler >> simplicity, or an accidental omission in the text. It really is that >> simple. > > What matters, ultimately, is what compilers would need to do to process > code in a fashion consistent with the purpose thereof. You've got it ass-backwards. Compiler writers write compilers that correctly compile code that is written to the C standards. It is the C programmer's job to write code that is written to the C standards in order to use the compiler. It is certainly /not/ the compiler writer's job to try to guess what some C programmers might have meant when writing code that does not follow the standards. > >>> Most practical code would work "by happenstance" even with gcc. On the >>> other hand, a compiler which can't process the above code in accordance >>> with what the Standard actually says should not be trusted to reliably >>> process practical code either. >> >> Yes, clearly gcc is not a tool to rely on for compiling C. The whole of >> the programming world should throw it out immediately. > > The -fno-strict-aliasing dialect is processed reliably. The > -fstrict-aliasing dialect should not be trusted with code that may need > the Effective Type of any object to change during its lifetime, even > though the Standard requires compilers to support such code. The rules > as written are unworkable unless a compiler is willing to forego what > should be useful optimization opportunities; gcc could be both simpler > and better if it had a non-conforming mode for use with programs that > don't need to change objects' effective types and a less aggressive mode > that was willing to forego optimizations in exchange for being able to > handle all required cases easily. Back here in the real world, most code is compiled for gcc with optimisation enabled and -fstrict-aliasing in effect. You are simply /wrong/ here. > >> If you think that gcc is wrong, file a bug. Smarter minds than yours >> will look at it and compare it to the standards, and see if the compiler >> needs to be changed. > > Some bugs have been filed, but the fundamental problem is that the Standard > is only designed to allow for a certain level of optimization but the > authors of gcc are trying to go beyond what the Standard is designed for, > rather than offering a mode that is documented as non-conforming, but which > could be very useful for certain kinds of programs. There you go again, imagining what you think the standard is designed for, instead of looking at what it says.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-01 11:03 -0800 |
| Message-ID | <4cb3cf48-9318-456b-9949-08c49599c9bc@googlegroups.com> |
| In reply to | #127171 |
On Thursday, March 1, 2018 at 5:38:09 AM UTC-6, David Brown wrote:
> On 01/03/18 00:19, supercat@casperkitty.com wrote:
> > Most code performs tasks that would be practical on an open-ended set
> > of platforms, but not on every imaginable platform. I would suggest that
> > making such code portable among general-purpose implementations for
> > platforms that can support it would be both practical and useful. The
> > reason so little code is portable is that the Standard fails to provide
> > means to accomplish many tasks in portable fashion.
>
> Stop "suggesting", and try thinking. Most code is written for a
> specific purpose. The programs written by companies in-house, or
> compiled and delivered as executables, far outweigh the code in
> libraries, or available as open source, or otherwise being widely portable.
Some projects are single-shot affairs whose code will be needed once to
produce a hex file to 'burn' a bunch of chips and never again used after
that. Many others have code that may need to be reused and adapted for
a variety of reasons. If code was produced using a compiler whose vendor
went out of business before writing a non-MS-DOS version and someone else
comes in to work on it, being able to have the same code be reliably usable
on a more recent development platform would seem better than having to
rewrite it.
Further, while it may be possible for every library to define its own set
of "compatibility macros" for things like enforcing the sequence of loads
and stores, fetching a 32-bit little-endian value from an aligned void*,
etc. having a standard set of such things would seem easier for all
concerned than having each library define its own set. People writing
code wouldn't have to take the time to write their own sets of compatibility
macros, people reading code would know what various functions do without
having to look up implementations thereof, and compiler writers could
implement features as intrinsics without having to recognize and optimize
the code patterns that would otherwise be used to implement them.
Also, as a general matter of philosophy, if most platforms could practically
support a behavior, and there any significant quantity of code would benefit
from it, what disadvantage would there be to defining the behavior for all
implementations that do not pre-define macro STDC_NO_whatever, but not
imposing any requirements on implementations that do define that macro?
Specifying such a thing once in the Standard and allowing programmers to say
#if defined(STDC_NO_whatever)
#error This program needs whatever
#endif
would seem easier, cleaner, and safer, than requiring that every
implementation that supports a feature document it, requiring that every
programmer who wants to use the feature document it in "human-readable"
form, and requiring that anyone wanting to use the code must read through
the documentation of their implementation to see if it is supported, and
bug the vendor if it isn't.
> So for most code, portability is irrelevant. The code /might/ be
> portable to any C compiler and any target, or it /might/ be portable to
> a range of similar targets or compilers - or it might be tied tightly to
> one compiler or one target. In most cases, the programmer does not
> care. This has nothing to do with what the standards say or don't say -
> it is a matter of what professional programmers do for a living.
There is a substantial plurality of code for which portability would be
useful. Hardware platforms do sometimes get superseded, and things like
multi-pool memory-management and storage-management routines should not
need to be tied to particular platforms outside of issues of data sizes,
endian-ness, and possibly alignment [even when coding for an 8-bit machine,
it's often good to align things as one would on a larger machine absent a
reason to do otherwise].
> > If an implementation uses two's-complement integers and neither signed nor
> > unsigned types include padding bits, what latitude would C89 give it to
> > process x<<1 as yielding anything other than x*2 in any case where the
> > latter would be defined?
>
> C89 did not define what "left shifting" of a signed type means. You can
> make some guesses, based on other definitions and try to get a
> consistent picture. In particular, you can assume that if all values
> are valid and can be represented, then left-shifting an unsigned value
> as an unsigned type or a signed type should give the same result. That
> means "left shifting" must be in terms of logical bit value positions,
> rather than the bits in the underlying representation. But what happens
> when you left-shift a signed integer? There is no definition of what
> that might mean in the C89 standards - it is undefined behaviour, and
> can't even be guessed from other points. In particular, it is /not/
> implementation-defined behaviour (which needs to be stated explicitly,
> as is the case for right-shifting negative numbers). The nearest you
> could guess is that it is an exceptional condition, and therefore
> undefined behaviour.
If you say there is latitude in how a two's-complement implementation where
neither "int" nor "unsigned" orders its bits for purposes of the << operator,
perhaps you can describe any implementation--no matter how contrived or
hypothetical--which satisfies the following constraints:
1. Uses two's-complement representation, and neither "int" nor "unsigned"
has any padding bits.
2. For every number in the range 0 to INT_MAX, the bit patterns for
signed and unsigned types would be identical.
3. The sign bit is something other than the leftmost bit.
Otherwise, is there any advantage to the current wording versus saying that
in cases where y within range of 0 to "int_bits"-1 and shifting the bit
pattern of x left y places and discarding the upper bits would yield the
number (x * 2**y), it will yield that value, and that behavior is undefined
in other cases? Code to scale values by configurable amounts could then
be written in a way which suggests that its purpose is to scale values
rather than manipulate bits. Further, if an implementation includes options
to trap overflow, such a feature would be more useful if programmers didn't
have to block it when using shifts to scale signed values.
> C99 did not change anything here. The text clarified that left-shifting
> negative numbers is undefined behaviour. The C99 rationale backs this
> up - it does not mention the point, which it would have done if it had
> been a change.
Most common implementations satisfy points #1-2 above. Under C89, the
semantics of a signed left shift would be defined for all values unless
an implementation also defines #3. Can you contrive an implementation
that meets all 3? If not, I'd say the behavior of left-shift was defined
on C89 for all implementations meeting #1 and #2.
> You can well say that left-shifting a negative number /should/ give x*2,
> at least on two's complement systems. Or you could say it /should/ be
> implementation-defined. But it is /not/ defined like that, and never
> has been. (And as always, implementations or other standards can give
> it a definition - it is merely undefined by the C standards.)
Under C89, it was defined in such a way that it would have been impossible
for an implementation to do anything else unless its integer types used
padding bits, or represented signed types using something other than
two's-complement format.
> > If a Committee were to act in sufficiently outrageous fashion, it would
> > be right and proper for everyone to ignore any standard they might publish.
> > People may differ with regard to what level of conduct should be viewed as
> > "sufficiently outrageous", and may regard as infinitesimal the likelihood of
> > the Committee acting in such fashion. Nonetheless, any authority the
> > Committee may have should be predicated upon its acting at least somewhat
> > reasonably.
>
> And most people - C programmers, and C compiler writers - agree that the
> committee is basically reasonable. Pretty much everyone has points in
> the standards that they would prefer to be defined differently, or at
> least explained differently. But the standards certainly work well
> enough that they are a useful standard.
The only reason the Standard is useful is that implementations go beyond
meeting its explicit requirements in cases where it is sensible to do so.
I don't think anyone has yet identified anything in the C89 Standard that
would allow an object to be treated as though it were an array of character
type, but the authors clearly expected that quality implementations would
do so. Even C11, however, fails to specify that. It does specify that
converting an object's address to char* and repeatedly incrementing it
will yield the addresses of the bytes in the object, but it does not
specify that the object may be treated as an array in any other regard,
nor does it specify the effect of any other form of pointer arithmetic
on that resulting pointer.
Certainly there are many tasks that would be rather difficult to do
efficiently without being able to do more array-like things with the bytes
of an object, and it would be rather absurd to suggest that someone wanting
to add a positive displacement to a byte pointer should write:
char *index_ptr(char *p, size_t n)
{
while(--n) p++;
return p;
}
which would run in time O(N) unless a compiler happened to optimize it
(which some very well might), or that someone wanting to efficiently
work through the bytes of an object in reverse order should have to
keep copies of at least some the addresses passed while computing the
last address to avoid having what should be an O(N) operation turn into
O(N*N) [with the likely effect being an O(NlgN) implementation that a
compiler would be unable to flatten to O(N).]
> A few people - such as yourself - get hung up about minor little details
> that are irrelevant to most code, and easily avoided. If you are
> "outraged" by the inability to left-shift negative numbers safely, then
> I think you need to re-tune your "outrage" filters.
What I am outraged about is the idea that code which had a useful defined
meaning should be reclassified as "undefined behavior" for, so far as I can
tell, no reason whatsoever. If compiler writers could be safely relied upon
to say that behavior that was ever defined will remain thus, whether or not
the Standard requires it, except in cases where a programmer *explicitly*
says that it is no longer needed, that wouldn't be a problem. So far as
I can tell, they cannot.
> > If the Committee decides to make a change which would break some existing
> > code after they have weighed their options and determined that the advantages
> > would outweigh the disadvantages, such action may be reasonable. If they
> > intend to break existing code for no reason whatsoever, that would be far
> > less reasonable.
>
> The Committee didn't change anything here. And one of the prime
> functions of the Committee has always been to look at existing code and
> practices, and ensure that they /don't/ make breaking changes without
> extremely good reason. Most of the poor points about the C language
> stem precisely from that principle.
Such principle only holds if one assumes that the authors of the Standard
intend that compiler writers treat UB as license to use judgment as to
what behaviors their customers need, rather than as representing a judgment
by the Committee about what the customers do or should need.
> > What matters, ultimately, is what compilers would need to do to process
> > code in a fashion consistent with the purpose thereof.
>
> You've got it ass-backwards.
>
> Compiler writers write compilers that correctly compile code that is
> written to the C standards. It is the C programmer's job to write code
> that is written to the C standards in order to use the compiler.
What was the job of C compilers prior to the publication of C89? It
can't have been to uphold a standard that didn't exist. If one wants
something that still does the job that C compilers did prior to the
publication of C89, what would such a thing be called?
> It is certainly /not/ the compiler writer's job to try to guess what
> some C programmers might have meant when writing code that does not
> follow the standards.
What "guessing" is required? If an action maps to some hardware operations
which behaves in a fashion consistent with the Standard in all cases
where it poses requirements, and it also describes the action in some
other terms that could be applied even in cases where the Standard imposes
no requirements, choose in Unspecified fashion from among the hardware
operations or the generally-described behavior. If multiple behaviors
would fit the above description, don't try to "guess" which is right--simply
pick from among them in any convenient fashion.
For example, on a typical platform, applying that principle to x>>n when
x is a uint32_t and n==32 might either yield x or 0, but if that appears
in an expression like (x<<y)|(x>>(32-y)), then the program would work just
as well with either behavior.
On many platforms, the language that would result by following the above
description would be sufficient to self-host an operating system given as
sole prerequisites a description of the underlying hardware platform and
a means of making the compiler generate a code image that is suitable for
the hardware's memory map and would start the main() in a full-privilege
mode. The Standard may not recognize a category of self-hosting C
implementations, but I think it's a useful classification.
> > The -fno-strict-aliasing dialect is processed reliably. The
> > -fstrict-aliasing dialect should not be trusted with code that may need
> > the Effective Type of any object to change during its lifetime, even
> > though the Standard requires compilers to support such code. The rules
> > as written are unworkable unless a compiler is willing to forego what
> > should be useful optimization opportunities; gcc could be both simpler
> > and better if it had a non-conforming mode for use with programs that
> > don't need to change objects' effective types and a less aggressive mode
> > that was willing to forego optimizations in exchange for being able to
> > handle all required cases easily.
>
> Back here in the real world, most code is compiled for gcc with
> optimisation enabled and -fstrict-aliasing in effect. You are simply
> /wrong/ here.
GCC will elide code that reads storage as one type and then writes it as
another if it determines that the bit pattern being written matches what
the storage previously held. It will then proceed to treat the storage
as though it still has the earlier Effective Type. While it would be
rare for this to occur in real code, it would be hard to guarantee that
there is no sequence of events via which it could occur.
What is ironic is that compilers really shouldn't have any reason to care
about Effective Type as C99 defines the term, but the Standard forces lots
of needless and unworkable complexity while blocking many useful
optimizations. Many of the "permissions" given to programmers by 6.5.6
and 6.5.7 are obstacles to optimization that would be unnecessary if the
Standard were to make clear a simple principle: the code
int *ip = someStruct->member;
// other code that doesn't access the storage identified by *ip
*ip = 1;
has defined behavior in cases where someStruct identifies a structure
of proper type not because the type of pointer *ip is contained within
someStruct [note that such a thing is completely irrelevant to 6.5.7,
since an "int" would not in general be a legal lvalue type to use when
accessing a someStruct], but rather because the access made using *ip
is really an access to a someStruct, and that fact would be visible to
any compiler that bothered to look.
> >> If you think that gcc is wrong, file a bug. Smarter minds than yours
> >> will look at it and compare it to the standards, and see if the compiler
> >> needs to be changed.
> >
> > Some bugs have been filed, but the fundamental problem is that the Standard
> > is only designed to allow for a certain level of optimization but the
> > authors of gcc are trying to go beyond what the Standard is designed for,
> > rather than offering a mode that is documented as non-conforming, but which
> > could be very useful for certain kinds of programs.
>
> There you go again, imagining what you think the standard is designed
> for, instead of looking at what it says.
Someone who is seeking to write a quality compiler suitable for a certain
purpose should make decisions based upon reasoned judgments about what
would make the compiler suitable for that purpose. If the Standard is
intended to offer reasoned judgment on some particular issue, it may make
sense to trust such judgment absent a reason to do otherwise. It does
not, however, make sense to interpret the Standard as offering reasoned
judgments on issues where it makes no effort to do so.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-03-01 11:22 -0800 |
| Message-ID | <lnd10nha8b.fsf@kst-u.example.com> |
| In reply to | #127185 |
supercat@casperkitty.com writes:
[...]
> Also, as a general matter of philosophy, if most platforms could practically
> support a behavior, and there any significant quantity of code would benefit
> from it, what disadvantage would there be to defining the behavior for all
> implementations that do not pre-define macro STDC_NO_whatever, but not
> imposing any requirements on implementations that do define that macro?
Clutter.
How many such behaviors should the standard define? How many
optional __STD_NO_whatever__ macros would have to be predefined?
By how many pages would the standard have to expand in order to
define the semantics of all these optional features?
You should start collecting all your ideas for changes to the
standard and put them all together in one place. Start a blog,
or create a GitHub repo, or whatever. I don't suggest that this
would make it likely that they'd be adopted, but vague complaints
posted to a newsgroup, interspersed with accusations about the
motivations of committee members and gcc maintainers, aren't going
to get anything done.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-03-01 11:48 -0800 |
| Message-ID | <6b621929-5c4f-4656-b676-a2faa1ceccee@googlegroups.com> |
| In reply to | #127189 |
On Thursday, March 1, 2018 at 12:22:39 PM UTC-7, Keith Thompson wrote: > supercat@casperkitty.com writes: > [...] > > Also, as a general matter of philosophy, if most platforms could practically > > support a behavior, and there any significant quantity of code would benefit > > from it, what disadvantage would there be to defining the behavior for all > > implementations that do not pre-define macro STDC_NO_whatever, but not > > imposing any requirements on implementations that do define that macro? > > Clutter. > > How many such behaviors should the standard define? How many > optional __STD_NO_whatever__ macros would have to be predefined? > By how many pages would the standard have to expand in order to > define the semantics of all these optional features? > > You should start collecting all your ideas for changes to the > standard and put them all together in one place. Start a blog, > or create a GitHub repo, or whatever. I don't suggest that this > would make it likely that they'd be adopted, but vague complaints > posted to a newsgroup, interspersed with accusations about the > motivations of committee members and gcc maintainers, aren't going > to get anything done. > > [...] > > -- > Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> > Working, but not speaking, for JetHead Development, Inc. > "We must do something. This is something. Therefore, we must do this." > -- Antony Jay and Jonathan Lynn, "Yes Minister" -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Gee, no on saw more forgeries coming. LOL! -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.28 Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWJpfjAAoJEC03b6bOr/+drC0P/RZBxcLK8eFZ7QUKjlqJRqfj 66udasAYnovhi+C1bpBxXZIm8Xxg2+JDdVoMfw/d+5R8+KpEXpxK+4y9GB8NuBBz 98+LuNNIus0cXJ6goCyKZj5FUajHYIhgoEAb+O8F0pYMcqv08R39IddgVEQCasDZ 9QPXlQco0QOSD49BArlDa7qgwi17Rs2zkYnw27jEIVEuYlfhqj2T7Mcirwby4JD3 +1Geq5kCdeCtMG+z6gAdth0akrSMlYLAnixbYolEFm6wtg7DW2BrwVo7NTY8Zuy1 UjRrn8JAoHrCec82HulrBBEXC/dhti2SIszDnt1GnZSTB33p1plQgklUmmqN8Qvu To/TAz07YWAeUHcYSyHzmJuVbL0r9emcQD/AfB8CxAhh+p5F5kc2hfwAOmJ4cGpV +kIqUp7N1UXqSOXnFyxYz4HJv9/c0UPNXSY2QDPmaWd7AFrB80BcOw2yVS30jQwo QhBtvoj2t/FJi/G7KnIpGYl3ZFy7QxtNL6PnPW5y46EjzDbNEnMbETTxAzI24QGw x5xgyhdiyRnpCvyHFd21d09bYOrBHH6qe3NMVTRBPjh1MUaw1E8WhQo916Zvk4jz pD23EIt9uk79a2aD+EbC/vZHLPGTqlbI1bmYV5KlzJusIO2i939Cs/AhYcdM8mEQ WqdC0S1YIC7GfYk7riFe =F3OP -----END PGP SIGNATURE----- - Puppy Videos! https://youtu.be/OffkiSAsYo8 Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-03-01 15:11 -0800 |
| Message-ID | <99acd0c6-51ac-4cc7-ab32-161ad2e248c8@googlegroups.com> |
| In reply to | #127191 |
On Thursday, March 1, 2018 at 12:48:52 PM UTC-7, Steven Petruzzellis wrote: > On Thursday, March 1, 2018 at 12:22:39 PM UTC-7, Keith Thompson wrote: > > supercat@casperkitty.com writes: > > [...] > > > Also, as a general matter of philosophy, if most platforms could practically > > > support a behavior, and there any significant quantity of code would benefit > > > from it, what disadvantage would there be to defining the behavior for all > > > implementations that do not pre-define macro STDC_NO_whatever, but not > > > imposing any requirements on implementations that do define that macro? > > > > Clutter. > > > > How many such behaviors should the standard define? How many > > optional __STD_NO_whatever__ macros would have to be predefined? > > By how many pages would the standard have to expand in order to > > define the semantics of all these optional features? > > > > You should start collecting all your ideas for changes to the > > standard and put them all together in one place. Start a blog, > > or create a GitHub repo, or whatever. I don't suggest that this > > would make it likely that they'd be adopted, but vague complaints > > posted to a newsgroup, interspersed with accusations about the > > motivations of committee members and gcc maintainers, aren't going > > to get anything done. > > > > [...] > > > > -- > > Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> > > Working, but not speaking, for JetHead Development, Inc. > > "We must do something. This is something. Therefore, we must do this." > > -- Antony Jay and Jonathan Lynn, "Yes Minister" > > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Gee, no on saw more forgeries coming. LOL! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.28 > Comment: GPGTools - https://gpgtools.org > > iQIcBAEBCgAGBQJWJpfjAAoJEC03b6bOr/+drC0P/RZBxcLK8eFZ7QUKjlqJRqfj > 66udasAYnovhi+C1bpBxXZIm8Xxg2+JDdVoMfw/d+5R8+KpEXpxK+4y9GB8NuBBz > 98+LuNNIus0cXJ6goCyKZj5FUajHYIhgoEAb+O8F0pYMcqv08R39IddgVEQCasDZ > 9QPXlQco0QOSD49BArlDa7qgwi17Rs2zkYnw27jEIVEuYlfhqj2T7Mcirwby4JD3 > +1Geq5kCdeCtMG+z6gAdth0akrSMlYLAnixbYolEFm6wtg7DW2BrwVo7NTY8Zuy1 > UjRrn8JAoHrCec82HulrBBEXC/dhti2SIszDnt1GnZSTB33p1plQgklUmmqN8Qvu > To/TAz07YWAeUHcYSyHzmJuVbL0r9emcQD/AfB8CxAhh+p5F5kc2hfwAOmJ4cGpV > +kIqUp7N1UXqSOXnFyxYz4HJv9/c0UPNXSY2QDPmaWd7AFrB80BcOw2yVS30jQwo > QhBtvoj2t/FJi/G7KnIpGYl3ZFy7QxtNL6PnPW5y46EjzDbNEnMbETTxAzI24QGw > x5xgyhdiyRnpCvyHFd21d09bYOrBHH6qe3NMVTRBPjh1MUaw1E8WhQo916Zvk4jz > pD23EIt9uk79a2aD+EbC/vZHLPGTqlbI1bmYV5KlzJusIO2i939Cs/AhYcdM8mEQ > WqdC0S1YIC7GfYk7riFe > =F3OP > -----END PGP SIGNATURE----- > > - > Puppy Videos! > https://youtu.be/OffkiSAsYo8 > Jonas Eklundh Communication AB Gee, imagine Adam LeMond trying to pin his flapdoodle on me, no one has ever seen that before ¯\_(ツ)_/¯. Protected code is not enough to protect you. Adam LeMond proved himself to be a sophist by claiming he would not debate Jonathan Rhodes through veraciously trumpeting PLONK and then berating him anyhow by means of another poster. From how Adam LeMond posted - by showing ignorance of details of the OS and more - he has not worked on a data-intensive task before. If he had he would have understood the requirements of declaring variables! -- Curious how these posts are made? Email: mr@sandman.net
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-03-01 16:14 -0800 |
| Message-ID | <2191d5e3-945c-4acb-8492-4a3ba6662123@googlegroups.com> |
| In reply to | #127209 |
On Thursday, March 1, 2018 at 4:12:03 PM UTC-7, Steven Petruzzellis wrote: > On Thursday, March 1, 2018 at 12:48:52 PM UTC-7, Steven Petruzzellis wrote: > > On Thursday, March 1, 2018 at 12:22:39 PM UTC-7, Keith Thompson wrote: > > > supercat@casperkitty.com writes: > > > [...] > > > > Also, as a general matter of philosophy, if most platforms could practically > > > > support a behavior, and there any significant quantity of code would benefit > > > > from it, what disadvantage would there be to defining the behavior for all > > > > implementations that do not pre-define macro STDC_NO_whatever, but not > > > > imposing any requirements on implementations that do define that macro? > > > > > > Clutter. > > > > > > How many such behaviors should the standard define? How many > > > optional __STD_NO_whatever__ macros would have to be predefined? > > > By how many pages would the standard have to expand in order to > > > define the semantics of all these optional features? > > > > > > You should start collecting all your ideas for changes to the > > > standard and put them all together in one place. Start a blog, > > > or create a GitHub repo, or whatever. I don't suggest that this > > > would make it likely that they'd be adopted, but vague complaints > > > posted to a newsgroup, interspersed with accusations about the > > > motivations of committee members and gcc maintainers, aren't going > > > to get anything done. > > > > > > [...] > > > > > > -- > > > Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> > > > Working, but not speaking, for JetHead Development, Inc. > > > "We must do something. This is something. Therefore, we must do this." > > > -- Antony Jay and Jonathan Lynn, "Yes Minister" > > > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > Gee, no on saw more forgeries coming. LOL! > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG/MacGPG2 v2.0.28 > > Comment: GPGTools - https://gpgtools.org > > > > iQIcBAEBCgAGBQJWJpfjAAoJEC03b6bOr/+drC0P/RZBxcLK8eFZ7QUKjlqJRqfj > > 66udasAYnovhi+C1bpBxXZIm8Xxg2+JDdVoMfw/d+5R8+KpEXpxK+4y9GB8NuBBz > > 98+LuNNIus0cXJ6goCyKZj5FUajHYIhgoEAb+O8F0pYMcqv08R39IddgVEQCasDZ > > 9QPXlQco0QOSD49BArlDa7qgwi17Rs2zkYnw27jEIVEuYlfhqj2T7Mcirwby4JD3 > > +1Geq5kCdeCtMG+z6gAdth0akrSMlYLAnixbYolEFm6wtg7DW2BrwVo7NTY8Zuy1 > > UjRrn8JAoHrCec82HulrBBEXC/dhti2SIszDnt1GnZSTB33p1plQgklUmmqN8Qvu > > To/TAz07YWAeUHcYSyHzmJuVbL0r9emcQD/AfB8CxAhh+p5F5kc2hfwAOmJ4cGpV > > +kIqUp7N1UXqSOXnFyxYz4HJv9/c0UPNXSY2QDPmaWd7AFrB80BcOw2yVS30jQwo > > QhBtvoj2t/FJi/G7KnIpGYl3ZFy7QxtNL6PnPW5y46EjzDbNEnMbETTxAzI24QGw > > x5xgyhdiyRnpCvyHFd21d09bYOrBHH6qe3NMVTRBPjh1MUaw1E8WhQo916Zvk4jz > > pD23EIt9uk79a2aD+EbC/vZHLPGTqlbI1bmYV5KlzJusIO2i939Cs/AhYcdM8mEQ > > WqdC0S1YIC7GfYk7riFe > > =F3OP > > -----END PGP SIGNATURE----- > > > > - > > Puppy Videos! > > https://youtu.be/OffkiSAsYo8 > > Jonas Eklundh Communication AB > > > > Gee, imagine Adam LeMond trying to pin his flapdoodle on me, no one has ever seen that before ¯\_(ツ)_/¯. Protected code is not enough to protect you. Adam LeMond proved himself to be a sophist by claiming he would not debate Jonathan Rhodes through veraciously trumpeting PLONK and then berating him anyhow by means of another poster. From how Adam LeMond posted - by showing ignorance of details of the OS and more - he has not worked on a data-intensive task before. If he had he would have understood the requirements of declaring variables! > > -- > Curious how these posts are made? Email: mr@sandman.net But Kevin S Jervik feels the need to belittle the herd. Oh goodness, that is just tons of rubbish. The content is a bunch of randomized bullshit. Which means... Now Autumn Nissen on the other end of the line doesn't matter. All that matters is Kevin S Jervik gets to deliver the attack. So how to respond? Don't reply to the post. Logic isn't part of ruse and never can be. I have a Systemd system I use as well, but it's a bit different. He pisses off an entire group of people who are mere civilians, but that's a stuck up jerk for you. What you and I care about isn't a factor. Nobody gets it, only Autumn Nissen gets it. Can you get less dishonest? - Curious how these posts are made? www.youtube.com/watch?v=0ZNxaaKD7-c
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-03-01 19:53 -0800 |
| Message-ID | <2d1b17b9-7a4f-4077-b8af-8ceca7aee505@googlegroups.com> |
| In reply to | #127212 |
On Thursday, March 1, 2018 at 5:14:39 PM UTC-7, Steven Petruzzellis wrote: > On Thursday, March 1, 2018 at 4:12:03 PM UTC-7, Steven Petruzzellis wrote: > > On Thursday, March 1, 2018 at 12:48:52 PM UTC-7, Steven Petruzzellis wrote: > > > On Thursday, March 1, 2018 at 12:22:39 PM UTC-7, Keith Thompson wrote: > > > > supercat@casperkitty.com writes: > > > > [...] > > > > > Also, as a general matter of philosophy, if most platforms could practically > > > > > support a behavior, and there any significant quantity of code would benefit > > > > > from it, what disadvantage would there be to defining the behavior for all > > > > > implementations that do not pre-define macro STDC_NO_whatever, but not > > > > > imposing any requirements on implementations that do define that macro? > > > > > > > > Clutter. > > > > > > > > How many such behaviors should the standard define? How many > > > > optional __STD_NO_whatever__ macros would have to be predefined? > > > > By how many pages would the standard have to expand in order to > > > > define the semantics of all these optional features? > > > > > > > > You should start collecting all your ideas for changes to the > > > > standard and put them all together in one place. Start a blog, > > > > or create a GitHub repo, or whatever. I don't suggest that this > > > > would make it likely that they'd be adopted, but vague complaints > > > > posted to a newsgroup, interspersed with accusations about the > > > > motivations of committee members and gcc maintainers, aren't going > > > > to get anything done. > > > > > > > > [...] > > > > > > > > -- > > > > Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> > > > > Working, but not speaking, for JetHead Development, Inc. > > > > "We must do something. This is something. Therefore, we must do this." > > > > -- Antony Jay and Jonathan Lynn, "Yes Minister" > > > > > > > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA512 > > > > > > Gee, no on saw more forgeries coming. LOL! > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG/MacGPG2 v2.0.28 > > > Comment: GPGTools - https://gpgtools.org > > > > > > iQIcBAEBCgAGBQJWJpfjAAoJEC03b6bOr/+drC0P/RZBxcLK8eFZ7QUKjlqJRqfj > > > 66udasAYnovhi+C1bpBxXZIm8Xxg2+JDdVoMfw/d+5R8+KpEXpxK+4y9GB8NuBBz > > > 98+LuNNIus0cXJ6goCyKZj5FUajHYIhgoEAb+O8F0pYMcqv08R39IddgVEQCasDZ > > > 9QPXlQco0QOSD49BArlDa7qgwi17Rs2zkYnw27jEIVEuYlfhqj2T7Mcirwby4JD3 > > > +1Geq5kCdeCtMG+z6gAdth0akrSMlYLAnixbYolEFm6wtg7DW2BrwVo7NTY8Zuy1 > > > UjRrn8JAoHrCec82HulrBBEXC/dhti2SIszDnt1GnZSTB33p1plQgklUmmqN8Qvu > > > To/TAz07YWAeUHcYSyHzmJuVbL0r9emcQD/AfB8CxAhh+p5F5kc2hfwAOmJ4cGpV > > > +kIqUp7N1UXqSOXnFyxYz4HJv9/c0UPNXSY2QDPmaWd7AFrB80BcOw2yVS30jQwo > > > QhBtvoj2t/FJi/G7KnIpGYl3ZFy7QxtNL6PnPW5y46EjzDbNEnMbETTxAzI24QGw > > > x5xgyhdiyRnpCvyHFd21d09bYOrBHH6qe3NMVTRBPjh1MUaw1E8WhQo916Zvk4jz > > > pD23EIt9uk79a2aD+EbC/vZHLPGTqlbI1bmYV5KlzJusIO2i939Cs/AhYcdM8mEQ > > > WqdC0S1YIC7GfYk7riFe > > > =F3OP > > > -----END PGP SIGNATURE----- > > > > > > - > > > Puppy Videos! > > > https://youtu.be/OffkiSAsYo8 > > > Jonas Eklundh Communication AB > > > > > > > > Gee, imagine Adam LeMond trying to pin his flapdoodle on me, no one has ever seen that before ¯\_(ツ)_/¯. Protected code is not enough to protect you. Adam LeMond proved himself to be a sophist by claiming he would not debate Jonathan Rhodes through veraciously trumpeting PLONK and then berating him anyhow by means of another poster. From how Adam LeMond posted - by showing ignorance of details of the OS and more - he has not worked on a data-intensive task before. If he had he would have understood the requirements of declaring variables! > > > > -- > > Curious how these posts are made? Email: mr@sandman.net > > > > But Kevin S Jervik feels the need to belittle the herd. Oh goodness, that is just tons of rubbish. > > The content is a bunch of randomized bullshit. Which means... > > Now Autumn Nissen on the other end of the line doesn't matter. All that matters is Kevin S Jervik gets to deliver the attack. So how to respond? Don't reply to the post. Logic isn't part of ruse and never can be. I have a Systemd system I use as well, but it's a bit different. He pisses off an entire group of people who are mere civilians, but that's a stuck up jerk for you. What you and I care about isn't a factor. > > Nobody gets it, only Autumn Nissen gets it. Can you get less dishonest? > > > > - > Curious how these posts are made? www.youtube.com/watch?v=0ZNxaaKD7-c Yup. It seems this is what we have to put up with. Cretins who obviously have no reason for being here other than to flood. The herd's done a pretty good job with a Markv model to automate texts which are made to sound like a response from a previous post in the group. Advertising is a wonderful thing and consumer stupidity is even better. Proof Sandman accuses everyone of being Snit http://sandman.net/files/snit_circus.png. Time to blame Adam LeMond! My uptime is almost seventy-seven days and Tmux is still going strong! When I was new here, I wanted to be unprejudiced and nonjudgemental. I gave Adam LeMond more than a wise person could be expected to. -- Live on Kickstarter!! http://www.5z8.info/dogs-being-eaten_g0w7hf_molotovcocktail https://www.youtube.com/watch?v=0ZNxaaKD7-c https://youtu.be/HMx0RyzbPgQ Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-03-01 21:27 -0800 |
| Message-ID | <5b8d59d8-9f24-4de1-bc59-31b10b284b90@googlegroups.com> |
| In reply to | #127225 |
On Thursday, March 1, 2018 at 8:53:21 PM UTC-7, Steven Petruzzellis wrote: > On Thursday, March 1, 2018 at 5:14:39 PM UTC-7, Steven Petruzzellis wrote: > > On Thursday, March 1, 2018 at 4:12:03 PM UTC-7, Steven Petruzzellis wrote: > > > On Thursday, March 1, 2018 at 12:48:52 PM UTC-7, Steven Petruzzellis wrote: > > > > On Thursday, March 1, 2018 at 12:22:39 PM UTC-7, Keith Thompson wrote: > > > > > supercat@casperkitty.com writes: > > > > > [...] > > > > > > Also, as a general matter of philosophy, if most platforms could practically > > > > > > support a behavior, and there any significant quantity of code would benefit > > > > > > from it, what disadvantage would there be to defining the behavior for all > > > > > > implementations that do not pre-define macro STDC_NO_whatever, but not > > > > > > imposing any requirements on implementations that do define that macro? > > > > > > > > > > Clutter. > > > > > > > > > > How many such behaviors should the standard define? How many > > > > > optional __STD_NO_whatever__ macros would have to be predefined? > > > > > By how many pages would the standard have to expand in order to > > > > > define the semantics of all these optional features? > > > > > > > > > > You should start collecting all your ideas for changes to the > > > > > standard and put them all together in one place. Start a blog, > > > > > or create a GitHub repo, or whatever. I don't suggest that this > > > > > would make it likely that they'd be adopted, but vague complaints > > > > > posted to a newsgroup, interspersed with accusations about the > > > > > motivations of committee members and gcc maintainers, aren't going > > > > > to get anything done. > > > > > > > > > > [...] > > > > > > > > > > -- > > > > > Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> > > > > > Working, but not speaking, for JetHead Development, Inc. > > > > > "We must do something. This is something. Therefore, we must do this." > > > > > -- Antony Jay and Jonathan Lynn, "Yes Minister" > > > > > > > > > > > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > Hash: SHA512 > > > > > > > > Gee, no on saw more forgeries coming. LOL! > > > > -----BEGIN PGP SIGNATURE----- > > > > Version: GnuPG/MacGPG2 v2.0.28 > > > > Comment: GPGTools - https://gpgtools.org > > > > > > > > iQIcBAEBCgAGBQJWJpfjAAoJEC03b6bOr/+drC0P/RZBxcLK8eFZ7QUKjlqJRqfj > > > > 66udasAYnovhi+C1bpBxXZIm8Xxg2+JDdVoMfw/d+5R8+KpEXpxK+4y9GB8NuBBz > > > > 98+LuNNIus0cXJ6goCyKZj5FUajHYIhgoEAb+O8F0pYMcqv08R39IddgVEQCasDZ > > > > 9QPXlQco0QOSD49BArlDa7qgwi17Rs2zkYnw27jEIVEuYlfhqj2T7Mcirwby4JD3 > > > > +1Geq5kCdeCtMG+z6gAdth0akrSMlYLAnixbYolEFm6wtg7DW2BrwVo7NTY8Zuy1 > > > > UjRrn8JAoHrCec82HulrBBEXC/dhti2SIszDnt1GnZSTB33p1plQgklUmmqN8Qvu > > > > To/TAz07YWAeUHcYSyHzmJuVbL0r9emcQD/AfB8CxAhh+p5F5kc2hfwAOmJ4cGpV > > > > +kIqUp7N1UXqSOXnFyxYz4HJv9/c0UPNXSY2QDPmaWd7AFrB80BcOw2yVS30jQwo > > > > QhBtvoj2t/FJi/G7KnIpGYl3ZFy7QxtNL6PnPW5y46EjzDbNEnMbETTxAzI24QGw > > > > x5xgyhdiyRnpCvyHFd21d09bYOrBHH6qe3NMVTRBPjh1MUaw1E8WhQo916Zvk4jz > > > > pD23EIt9uk79a2aD+EbC/vZHLPGTqlbI1bmYV5KlzJusIO2i939Cs/AhYcdM8mEQ > > > > WqdC0S1YIC7GfYk7riFe > > > > =F3OP > > > > -----END PGP SIGNATURE----- > > > > > > > > - > > > > Puppy Videos! > > > > https://youtu.be/OffkiSAsYo8 > > > > Jonas Eklundh Communication AB > > > > > > > > > > > > Gee, imagine Adam LeMond trying to pin his flapdoodle on me, no one has ever seen that before ¯\_(ツ)_/¯. Protected code is not enough to protect you. Adam LeMond proved himself to be a sophist by claiming he would not debate Jonathan Rhodes through veraciously trumpeting PLONK and then berating him anyhow by means of another poster. From how Adam LeMond posted - by showing ignorance of details of the OS and more - he has not worked on a data-intensive task before. If he had he would have understood the requirements of declaring variables! > > > > > > -- > > > Curious how these posts are made? Email: mr@sandman.net > > > > > > > > But Kevin S Jervik feels the need to belittle the herd. Oh goodness, that is just tons of rubbish. > > > > The content is a bunch of randomized bullshit. Which means... > > > > Now Autumn Nissen on the other end of the line doesn't matter. All that matters is Kevin S Jervik gets to deliver the attack. So how to respond? Don't reply to the post. Logic isn't part of ruse and never can be. I have a Systemd system I use as well, but it's a bit different. He pisses off an entire group of people who are mere civilians, but that's a stuck up jerk for you. What you and I care about isn't a factor. > > > > Nobody gets it, only Autumn Nissen gets it. Can you get less dishonest? > > > > > > > > - > > Curious how these posts are made? www.youtube.com/watch?v=0ZNxaaKD7-c > > > > Yup. It seems this is what we have to put up with. Cretins who obviously have no reason for being here other than to flood. > > The herd's done a pretty good job with a Markv model to automate texts which are made to sound like a response from a previous post in the group. Advertising is a wonderful thing and consumer stupidity is even better. > > Proof Sandman accuses everyone of being Snit http://sandman.net/files/snit_circus.png. Time to blame Adam LeMond! My uptime is almost seventy-seven days and Tmux is still going strong! When I was new here, I wanted to be unprejudiced and nonjudgemental. I gave Adam LeMond more than a wise person could be expected to. > > > > -- > Live on Kickstarter!! > http://www.5z8.info/dogs-being-eaten_g0w7hf_molotovcocktail > https://www.youtube.com/watch?v=0ZNxaaKD7-c > https://youtu.be/HMx0RyzbPgQ > Jonas Eklundh Rambling cretin. Sadly there are too many "bugs are acceptable" false "advocates" and not enough old school users with the time to help the people with old computers. He pretends that he uses ChromeOS, while of course he never timed it to get any real work done and faithfully used it. - "You'll notice how quickly he loses interest when everything is about him. He clearly wants the attention" Steve Carroll, making the dumbest comment ever uttered.
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-03-02 00:52 -0800 |
| Message-ID | <9cced0cc-4e46-4eed-87fa-fe6e0aa4da4c@googlegroups.com> |
| In reply to | #127230 |
On Thursday, March 1, 2018 at 10:28:10 PM UTC-7, Steven Petruzzellis wrote: > On Thursday, March 1, 2018 at 8:53:21 PM UTC-7, Steven Petruzzellis wrote: > > On Thursday, March 1, 2018 at 5:14:39 PM UTC-7, Steven Petruzzellis wrote: > > > On Thursday, March 1, 2018 at 4:12:03 PM UTC-7, Steven Petruzzellis wrote: > > > > On Thursday, March 1, 2018 at 12:48:52 PM UTC-7, Steven Petruzzellis wrote: > > > > > On Thursday, March 1, 2018 at 12:22:39 PM UTC-7, Keith Thompson wrote: > > > > > > supercat@casperkitty.com writes: > > > > > > [...] > > > > > > > Also, as a general matter of philosophy, if most platforms could practically > > > > > > > support a behavior, and there any significant quantity of code would benefit > > > > > > > from it, what disadvantage would there be to defining the behavior for all > > > > > > > implementations that do not pre-define macro STDC_NO_whatever, but not > > > > > > > imposing any requirements on implementations that do define that macro? > > > > > > > > > > > > Clutter. > > > > > > > > > > > > How many such behaviors should the standard define? How many > > > > > > optional __STD_NO_whatever__ macros would have to be predefined? > > > > > > By how many pages would the standard have to expand in order to > > > > > > define the semantics of all these optional features? > > > > > > > > > > > > You should start collecting all your ideas for changes to the > > > > > > standard and put them all together in one place. Start a blog, > > > > > > or create a GitHub repo, or whatever. I don't suggest that this > > > > > > would make it likely that they'd be adopted, but vague complaints > > > > > > posted to a newsgroup, interspersed with accusations about the > > > > > > motivations of committee members and gcc maintainers, aren't going > > > > > > to get anything done. > > > > > > > > > > > > [...] > > > > > > > > > > > > -- > > > > > > Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> > > > > > > Working, but not speaking, for JetHead Development, Inc. > > > > > > "We must do something. This is something. Therefore, we must do this." > > > > > > -- Antony Jay and Jonathan Lynn, "Yes Minister" > > > > > > > > > > > > > > > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > > Hash: SHA512 > > > > > > > > > > Gee, no on saw more forgeries coming. LOL! > > > > > -----BEGIN PGP SIGNATURE----- > > > > > Version: GnuPG/MacGPG2 v2.0.28 > > > > > Comment: GPGTools - https://gpgtools.org > > > > > > > > > > iQIcBAEBCgAGBQJWJpfjAAoJEC03b6bOr/+drC0P/RZBxcLK8eFZ7QUKjlqJRqfj > > > > > 66udasAYnovhi+C1bpBxXZIm8Xxg2+JDdVoMfw/d+5R8+KpEXpxK+4y9GB8NuBBz > > > > > 98+LuNNIus0cXJ6goCyKZj5FUajHYIhgoEAb+O8F0pYMcqv08R39IddgVEQCasDZ > > > > > 9QPXlQco0QOSD49BArlDa7qgwi17Rs2zkYnw27jEIVEuYlfhqj2T7Mcirwby4JD3 > > > > > +1Geq5kCdeCtMG+z6gAdth0akrSMlYLAnixbYolEFm6wtg7DW2BrwVo7NTY8Zuy1 > > > > > UjRrn8JAoHrCec82HulrBBEXC/dhti2SIszDnt1GnZSTB33p1plQgklUmmqN8Qvu > > > > > To/TAz07YWAeUHcYSyHzmJuVbL0r9emcQD/AfB8CxAhh+p5F5kc2hfwAOmJ4cGpV > > > > > +kIqUp7N1UXqSOXnFyxYz4HJv9/c0UPNXSY2QDPmaWd7AFrB80BcOw2yVS30jQwo > > > > > QhBtvoj2t/FJi/G7KnIpGYl3ZFy7QxtNL6PnPW5y46EjzDbNEnMbETTxAzI24QGw > > > > > x5xgyhdiyRnpCvyHFd21d09bYOrBHH6qe3NMVTRBPjh1MUaw1E8WhQo916Zvk4jz > > > > > pD23EIt9uk79a2aD+EbC/vZHLPGTqlbI1bmYV5KlzJusIO2i939Cs/AhYcdM8mEQ > > > > > WqdC0S1YIC7GfYk7riFe > > > > > =F3OP > > > > > -----END PGP SIGNATURE----- > > > > > > > > > > - > > > > > Puppy Videos! > > > > > https://youtu.be/OffkiSAsYo8 > > > > > Jonas Eklundh Communication AB > > > > > > > > > > > > > > > > Gee, imagine Adam LeMond trying to pin his flapdoodle on me, no one has ever seen that before ¯\_(ツ)_/¯. Protected code is not enough to protect you. Adam LeMond proved himself to be a sophist by claiming he would not debate Jonathan Rhodes through veraciously trumpeting PLONK and then berating him anyhow by means of another poster. From how Adam LeMond posted - by showing ignorance of details of the OS and more - he has not worked on a data-intensive task before. If he had he would have understood the requirements of declaring variables! > > > > > > > > -- > > > > Curious how these posts are made? Email: mr@sandman.net > > > > > > > > > > > > But Kevin S Jervik feels the need to belittle the herd. Oh goodness, that is just tons of rubbish. > > > > > > The content is a bunch of randomized bullshit. Which means... > > > > > > Now Autumn Nissen on the other end of the line doesn't matter. All that matters is Kevin S Jervik gets to deliver the attack. So how to respond? Don't reply to the post. Logic isn't part of ruse and never can be. I have a Systemd system I use as well, but it's a bit different. He pisses off an entire group of people who are mere civilians, but that's a stuck up jerk for you. What you and I care about isn't a factor. > > > > > > Nobody gets it, only Autumn Nissen gets it. Can you get less dishonest? > > > > > > > > > > > > - > > > Curious how these posts are made? www.youtube.com/watch?v=0ZNxaaKD7-c > > > > > > > > Yup. It seems this is what we have to put up with. Cretins who obviously have no reason for being here other than to flood. > > > > The herd's done a pretty good job with a Markv model to automate texts which are made to sound like a response from a previous post in the group. Advertising is a wonderful thing and consumer stupidity is even better. > > > > Proof Sandman accuses everyone of being Snit http://sandman.net/files/snit_circus.png. Time to blame Adam LeMond! My uptime is almost seventy-seven days and Tmux is still going strong! When I was new here, I wanted to be unprejudiced and nonjudgemental. I gave Adam LeMond more than a wise person could be expected to. > > > > > > > > -- > > Live on Kickstarter!! > > http://www.5z8.info/dogs-being-eaten_g0w7hf_molotovcocktail > > https://www.youtube.com/watch?v=0ZNxaaKD7-c > > https://youtu.be/HMx0RyzbPgQ > > Jonas Eklundh > > > > Rambling cretin. Sadly there are too many "bugs are acceptable" false "advocates" and not enough old school users with the time to help the people with old computers. He pretends that he uses ChromeOS, while of course he never timed it to get any real work done and faithfully used it. > > - > "You'll notice how quickly he loses interest when everything is about him. He clearly wants the attention" > Steve Carroll, making the dumbest comment ever uttered. Asking Jonathan Rhodes to stop flooding is distinct from showing his fraud. My main idea was that advocates arrive here *to* engage those who disagree. It isn't like we all do not quickly figure out what this place is, Tatiana Spearman Kister included. If Jonathan Rhodes calls getting his ass *kicked hard* like an idiot by Tatiana Spearman Kister and me 'trolling', then whatever... he is a great troll. I don't subscribe to that meaning, I use another term. I call that person a perfect birdbrain. His hope is to see Tatiana Spearman Kister frustrated by having me get blamed for his actions. And hey, that could happen. The whole sham is chock-full of bizarre cracks and leans heavily on Jonathan Rhodes's 'home made CMS' nonsense. Only what Jonathan Rhodes wants matters to Jonathan Rhodes. There is nothing you or I can do to change that. It's a personality defect and it is what it is. -- Best CMS Solution of 2017 https://youtu.be/m37dF5X2S-4 http://www.5z8.info/hack-outlook_c6c9in_michaelangelo-virus https://youtu.be/m37dF5X2S-4 Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-03-02 01:54 -0800 |
| Message-ID | <9524b962-8820-47dc-a726-83cccdbcb3e2@googlegroups.com> |
| In reply to | #127230 |
On Thursday, March 1, 2018 at 10:28:10 PM UTC-7, Steven Petruzzellis wrote: > On Thursday, March 1, 2018 at 8:53:21 PM UTC-7, Steven Petruzzellis wrote: > > On Thursday, March 1, 2018 at 5:14:39 PM UTC-7, Steven Petruzzellis wrote: > > > On Thursday, March 1, 2018 at 4:12:03 PM UTC-7, Steven Petruzzellis wrote: > > > > On Thursday, March 1, 2018 at 12:48:52 PM UTC-7, Steven Petruzzellis wrote: > > > > > On Thursday, March 1, 2018 at 12:22:39 PM UTC-7, Keith Thompson wrote: > > > > > > supercat@casperkitty.com writes: > > > > > > [...] > > > > > > > Also, as a general matter of philosophy, if most platforms could practically > > > > > > > support a behavior, and there any significant quantity of code would benefit > > > > > > > from it, what disadvantage would there be to defining the behavior for all > > > > > > > implementations that do not pre-define macro STDC_NO_whatever, but not > > > > > > > imposing any requirements on implementations that do define that macro? > > > > > > > > > > > > Clutter. > > > > > > > > > > > > How many such behaviors should the standard define? How many > > > > > > optional __STD_NO_whatever__ macros would have to be predefined? > > > > > > By how many pages would the standard have to expand in order to > > > > > > define the semantics of all these optional features? > > > > > > > > > > > > You should start collecting all your ideas for changes to the > > > > > > standard and put them all together in one place. Start a blog, > > > > > > or create a GitHub repo, or whatever. I don't suggest that this > > > > > > would make it likely that they'd be adopted, but vague complaints > > > > > > posted to a newsgroup, interspersed with accusations about the > > > > > > motivations of committee members and gcc maintainers, aren't going > > > > > > to get anything done. > > > > > > > > > > > > [...] > > > > > > > > > > > > -- > > > > > > Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> > > > > > > Working, but not speaking, for JetHead Development, Inc. > > > > > > "We must do something. This is something. Therefore, we must do this." > > > > > > -- Antony Jay and Jonathan Lynn, "Yes Minister" > > > > > > > > > > > > > > > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > > Hash: SHA512 > > > > > > > > > > Gee, no on saw more forgeries coming. LOL! > > > > > -----BEGIN PGP SIGNATURE----- > > > > > Version: GnuPG/MacGPG2 v2.0.28 > > > > > Comment: GPGTools - https://gpgtools.org > > > > > > > > > > iQIcBAEBCgAGBQJWJpfjAAoJEC03b6bOr/+drC0P/RZBxcLK8eFZ7QUKjlqJRqfj > > > > > 66udasAYnovhi+C1bpBxXZIm8Xxg2+JDdVoMfw/d+5R8+KpEXpxK+4y9GB8NuBBz > > > > > 98+LuNNIus0cXJ6goCyKZj5FUajHYIhgoEAb+O8F0pYMcqv08R39IddgVEQCasDZ > > > > > 9QPXlQco0QOSD49BArlDa7qgwi17Rs2zkYnw27jEIVEuYlfhqj2T7Mcirwby4JD3 > > > > > +1Geq5kCdeCtMG+z6gAdth0akrSMlYLAnixbYolEFm6wtg7DW2BrwVo7NTY8Zuy1 > > > > > UjRrn8JAoHrCec82HulrBBEXC/dhti2SIszDnt1GnZSTB33p1plQgklUmmqN8Qvu > > > > > To/TAz07YWAeUHcYSyHzmJuVbL0r9emcQD/AfB8CxAhh+p5F5kc2hfwAOmJ4cGpV > > > > > +kIqUp7N1UXqSOXnFyxYz4HJv9/c0UPNXSY2QDPmaWd7AFrB80BcOw2yVS30jQwo > > > > > QhBtvoj2t/FJi/G7KnIpGYl3ZFy7QxtNL6PnPW5y46EjzDbNEnMbETTxAzI24QGw > > > > > x5xgyhdiyRnpCvyHFd21d09bYOrBHH6qe3NMVTRBPjh1MUaw1E8WhQo916Zvk4jz > > > > > pD23EIt9uk79a2aD+EbC/vZHLPGTqlbI1bmYV5KlzJusIO2i939Cs/AhYcdM8mEQ > > > > > WqdC0S1YIC7GfYk7riFe > > > > > =F3OP > > > > > -----END PGP SIGNATURE----- > > > > > > > > > > - > > > > > Puppy Videos! > > > > > https://youtu.be/OffkiSAsYo8 > > > > > Jonas Eklundh Communication AB > > > > > > > > > > > > > > > > Gee, imagine Adam LeMond trying to pin his flapdoodle on me, no one has ever seen that before ¯\_(ツ)_/¯. Protected code is not enough to protect you. Adam LeMond proved himself to be a sophist by claiming he would not debate Jonathan Rhodes through veraciously trumpeting PLONK and then berating him anyhow by means of another poster. From how Adam LeMond posted - by showing ignorance of details of the OS and more - he has not worked on a data-intensive task before. If he had he would have understood the requirements of declaring variables! > > > > > > > > -- > > > > Curious how these posts are made? Email: mr@sandman.net > > > > > > > > > > > > But Kevin S Jervik feels the need to belittle the herd. Oh goodness, that is just tons of rubbish. > > > > > > The content is a bunch of randomized bullshit. Which means... > > > > > > Now Autumn Nissen on the other end of the line doesn't matter. All that matters is Kevin S Jervik gets to deliver the attack. So how to respond? Don't reply to the post. Logic isn't part of ruse and never can be. I have a Systemd system I use as well, but it's a bit different. He pisses off an entire group of people who are mere civilians, but that's a stuck up jerk for you. What you and I care about isn't a factor. > > > > > > Nobody gets it, only Autumn Nissen gets it. Can you get less dishonest? > > > > > > > > > > > > - > > > Curious how these posts are made? www.youtube.com/watch?v=0ZNxaaKD7-c > > > > > > > > Yup. It seems this is what we have to put up with. Cretins who obviously have no reason for being here other than to flood. > > > > The herd's done a pretty good job with a Markv model to automate texts which are made to sound like a response from a previous post in the group. Advertising is a wonderful thing and consumer stupidity is even better. > > > > Proof Sandman accuses everyone of being Snit http://sandman.net/files/snit_circus.png. Time to blame Adam LeMond! My uptime is almost seventy-seven days and Tmux is still going strong! When I was new here, I wanted to be unprejudiced and nonjudgemental. I gave Adam LeMond more than a wise person could be expected to. > > > > > > > > -- > > Live on Kickstarter!! > > http://www.5z8.info/dogs-being-eaten_g0w7hf_molotovcocktail > > https://www.youtube.com/watch?v=0ZNxaaKD7-c > > https://youtu.be/HMx0RyzbPgQ > > Jonas Eklundh > > > > Rambling cretin. Sadly there are too many "bugs are acceptable" false "advocates" and not enough old school users with the time to help the people with old computers. He pretends that he uses ChromeOS, while of course he never timed it to get any real work done and faithfully used it. > > - > "You'll notice how quickly he loses interest when everything is about him. He clearly wants the attention" > Steve Carroll, making the dumbest comment ever uttered. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 - -- sex n 1. either of the two reproductive categories, male or female, of animals and plants 2. sexual intercourse 3. sexual activity or behavior leading to it 4. the genitals (literary) 5. the set of characteristics that determine whether the reproductive role of an animal or plant is male or female - -- And, notably, Snit wrote: "Sex is a subset of sexual activities" - Snit - (I guess he didn't comprehend point 3 very well) Of course, he also wrote: "Sexual activities are sex by definition, you moron" - Snit And this: "A passionate kiss could be called a "sexual activity" but it is not sex" In Snit's world, a passionate kiss is not sex... but it is sex. LOL! -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVRYvKAAoJEC03b6bOr/+dgbUP/icm7kQOjm2kSNou+JmBBgHb A4tmqQKGn3RwkS88wbmhuGrc7bj+Mn0olYmozNufRMG1hB+cjJR/a3K4qEN+hZP7 6KNdfvYKxSOcdtrsYEezCOPK6yu9tlwspR5w61vMaEWxmGX8CZ8FuZWnZhiul1CA WXRpPDK8GJnWecK7wqDw8wJCKu4ENRw0AUTFWdmmGIUO1n3x/NSbCXIftMop4MBd 9NHP3v26pA5NB9tlh//BtQa8Ys03DASuViFd1VRgtuL4wSnctDDLUE4zQGp+GcS7 DOhjROy9ExDGqer4uLwPwDD59eUef8s4WI/XRivl2uQSl7rs/XWKw4OStOzXajGX EMcJ4c9zPjtwKB2F781+U3DH2l9YLBii/UZCpgcblvvuXSb/b/7D64AxpzvEfPpZ TTq/OcOEDsbhaOijEdELMw/IjuQ+Pp+5cMEOey7BK3uPAjr8gOLU0xmChJimNP8r o9RzphsO8O+mJMK0sdke9FEJByCgX3LbJYro21v0ZS0Nt2JW16Z8VakHNKfUbuLg IYHbShHiEQ1GCWOQ+AIfpwG6td/NE/EhiCE9OixWAsvGq6e0w4k7vARG8hSfZDpp 3hp7rD8x9EVp4v4e7G34Wr6FIZlfYzD2fX6SRu9wYpG/v87sgvrN9klY1YLn/zig oZmOKJM5cC0iwnvHsavO =4yFU -----END PGP SIGNATURE----- -- E-commerce Simplified! https://youtu.be/GPPqvw8iEBs https://goo.gl/Fho5Nq Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-03-03 06:11 -0800 |
| Message-ID | <0f11899c-ca61-4429-9ae7-fdc20eb89040@googlegroups.com> |
| In reply to | #127244 |
On Friday, March 2, 2018 at 2:54:47 AM UTC-7, Steven Petruzzellis wrote: > On Thursday, March 1, 2018 at 10:28:10 PM UTC-7, Steven Petruzzellis wrote: > > On Thursday, March 1, 2018 at 8:53:21 PM UTC-7, Steven Petruzzellis wrote: > > > On Thursday, March 1, 2018 at 5:14:39 PM UTC-7, Steven Petruzzellis wrote: > > > > On Thursday, March 1, 2018 at 4:12:03 PM UTC-7, Steven Petruzzellis wrote: > > > > > On Thursday, March 1, 2018 at 12:48:52 PM UTC-7, Steven Petruzzellis wrote: > > > > > > On Thursday, March 1, 2018 at 12:22:39 PM UTC-7, Keith Thompson wrote: > > > > > > > supercat@casperkitty.com writes: > > > > > > > [...] > > > > > > > > Also, as a general matter of philosophy, if most platforms could practically > > > > > > > > support a behavior, and there any significant quantity of code would benefit > > > > > > > > from it, what disadvantage would there be to defining the behavior for all > > > > > > > > implementations that do not pre-define macro STDC_NO_whatever, but not > > > > > > > > imposing any requirements on implementations that do define that macro? > > > > > > > > > > > > > > Clutter. > > > > > > > > > > > > > > How many such behaviors should the standard define? How many > > > > > > > optional __STD_NO_whatever__ macros would have to be predefined? > > > > > > > By how many pages would the standard have to expand in order to > > > > > > > define the semantics of all these optional features? > > > > > > > > > > > > > > You should start collecting all your ideas for changes to the > > > > > > > standard and put them all together in one place. Start a blog, > > > > > > > or create a GitHub repo, or whatever. I don't suggest that this > > > > > > > would make it likely that they'd be adopted, but vague complaints > > > > > > > posted to a newsgroup, interspersed with accusations about the > > > > > > > motivations of committee members and gcc maintainers, aren't going > > > > > > > to get anything done. > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > -- > > > > > > > Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> > > > > > > > Working, but not speaking, for JetHead Development, Inc. > > > > > > > "We must do something. This is something. Therefore, we must do this." > > > > > > > -- Antony Jay and Jonathan Lynn, "Yes Minister" > > > > > > > > > > > > > > > > > > > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > > > Hash: SHA512 > > > > > > > > > > > > Gee, no on saw more forgeries coming. LOL! > > > > > > -----BEGIN PGP SIGNATURE----- > > > > > > Version: GnuPG/MacGPG2 v2.0.28 > > > > > > Comment: GPGTools - https://gpgtools.org > > > > > > > > > > > > iQIcBAEBCgAGBQJWJpfjAAoJEC03b6bOr/+drC0P/RZBxcLK8eFZ7QUKjlqJRqfj > > > > > > 66udasAYnovhi+C1bpBxXZIm8Xxg2+JDdVoMfw/d+5R8+KpEXpxK+4y9GB8NuBBz > > > > > > 98+LuNNIus0cXJ6goCyKZj5FUajHYIhgoEAb+O8F0pYMcqv08R39IddgVEQCasDZ > > > > > > 9QPXlQco0QOSD49BArlDa7qgwi17Rs2zkYnw27jEIVEuYlfhqj2T7Mcirwby4JD3 > > > > > > +1Geq5kCdeCtMG+z6gAdth0akrSMlYLAnixbYolEFm6wtg7DW2BrwVo7NTY8Zuy1 > > > > > > UjRrn8JAoHrCec82HulrBBEXC/dhti2SIszDnt1GnZSTB33p1plQgklUmmqN8Qvu > > > > > > To/TAz07YWAeUHcYSyHzmJuVbL0r9emcQD/AfB8CxAhh+p5F5kc2hfwAOmJ4cGpV > > > > > > +kIqUp7N1UXqSOXnFyxYz4HJv9/c0UPNXSY2QDPmaWd7AFrB80BcOw2yVS30jQwo > > > > > > QhBtvoj2t/FJi/G7KnIpGYl3ZFy7QxtNL6PnPW5y46EjzDbNEnMbETTxAzI24QGw > > > > > > x5xgyhdiyRnpCvyHFd21d09bYOrBHH6qe3NMVTRBPjh1MUaw1E8WhQo916Zvk4jz > > > > > > pD23EIt9uk79a2aD+EbC/vZHLPGTqlbI1bmYV5KlzJusIO2i939Cs/AhYcdM8mEQ > > > > > > WqdC0S1YIC7GfYk7riFe > > > > > > =F3OP > > > > > > -----END PGP SIGNATURE----- > > > > > > > > > > > > - > > > > > > Puppy Videos! > > > > > > https://youtu.be/OffkiSAsYo8 > > > > > > Jonas Eklundh Communication AB > > > > > > > > > > > > > > > > > > > > Gee, imagine Adam LeMond trying to pin his flapdoodle on me, no one has ever seen that before ¯\_(ツ)_/¯. Protected code is not enough to protect you. Adam LeMond proved himself to be a sophist by claiming he would not debate Jonathan Rhodes through veraciously trumpeting PLONK and then berating him anyhow by means of another poster. From how Adam LeMond posted - by showing ignorance of details of the OS and more - he has not worked on a data-intensive task before. If he had he would have understood the requirements of declaring variables! > > > > > > > > > > -- > > > > > Curious how these posts are made? Email: mr@sandman.net > > > > > > > > > > > > > > > > But Kevin S Jervik feels the need to belittle the herd. Oh goodness, that is just tons of rubbish. > > > > > > > > The content is a bunch of randomized bullshit. Which means... > > > > > > > > Now Autumn Nissen on the other end of the line doesn't matter. All that matters is Kevin S Jervik gets to deliver the attack. So how to respond? Don't reply to the post. Logic isn't part of ruse and never can be. I have a Systemd system I use as well, but it's a bit different. He pisses off an entire group of people who are mere civilians, but that's a stuck up jerk for you. What you and I care about isn't a factor. > > > > > > > > Nobody gets it, only Autumn Nissen gets it. Can you get less dishonest? > > > > > > > > > > > > > > > > - > > > > Curious how these posts are made? www.youtube.com/watch?v=0ZNxaaKD7-c > > > > > > > > > > > > Yup. It seems this is what we have to put up with. Cretins who obviously have no reason for being here other than to flood. > > > > > > The herd's done a pretty good job with a Markv model to automate texts which are made to sound like a response from a previous post in the group. Advertising is a wonderful thing and consumer stupidity is even better. > > > > > > Proof Sandman accuses everyone of being Snit http://sandman.net/files/snit_circus.png. Time to blame Adam LeMond! My uptime is almost seventy-seven days and Tmux is still going strong! When I was new here, I wanted to be unprejudiced and nonjudgemental. I gave Adam LeMond more than a wise person could be expected to. > > > > > > > > > > > > -- > > > Live on Kickstarter!! > > > http://www.5z8.info/dogs-being-eaten_g0w7hf_molotovcocktail > > > https://www.youtube.com/watch?v=0ZNxaaKD7-c > > > https://youtu.be/HMx0RyzbPgQ > > > Jonas Eklundh > > > > > > > > Rambling cretin. Sadly there are too many "bugs are acceptable" false "advocates" and not enough old school users with the time to help the people with old computers. He pretends that he uses ChromeOS, while of course he never timed it to get any real work done and faithfully used it. > > > > - > > "You'll notice how quickly he loses interest when everything is about him. He clearly wants the attention" > > Steve Carroll, making the dumbest comment ever uttered. > > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > - -- > sex n > 1. either of the two reproductive categories, male or female, of animals and plants > 2. sexual intercourse > 3. sexual activity or behavior leading to it > 4. the genitals (literary) > 5. the set of characteristics that determine whether the reproductive role of an animal or plant is male or female > - -- > > And, notably, Snit wrote: > "Sex is a subset of sexual activities" - Snit - (I guess he didn't comprehend point 3 very well) > > Of course, he also wrote: > "Sexual activities are sex by definition, you moron" - Snit > > And this: > "A passionate kiss could be called a "sexual activity" but it is not sex" > > In Snit's world, a passionate kiss is not sex... but it is sex. LOL! > > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - https://gpgtools.org > > iQIcBAEBCgAGBQJVRYvKAAoJEC03b6bOr/+dgbUP/icm7kQOjm2kSNou+JmBBgHb > A4tmqQKGn3RwkS88wbmhuGrc7bj+Mn0olYmozNufRMG1hB+cjJR/a3K4qEN+hZP7 > 6KNdfvYKxSOcdtrsYEezCOPK6yu9tlwspR5w61vMaEWxmGX8CZ8FuZWnZhiul1CA > WXRpPDK8GJnWecK7wqDw8wJCKu4ENRw0AUTFWdmmGIUO1n3x/NSbCXIftMop4MBd > 9NHP3v26pA5NB9tlh//BtQa8Ys03DASuViFd1VRgtuL4wSnctDDLUE4zQGp+GcS7 > DOhjROy9ExDGqer4uLwPwDD59eUef8s4WI/XRivl2uQSl7rs/XWKw4OStOzXajGX > EMcJ4c9zPjtwKB2F781+U3DH2l9YLBii/UZCpgcblvvuXSb/b/7D64AxpzvEfPpZ > TTq/OcOEDsbhaOijEdELMw/IjuQ+Pp+5cMEOey7BK3uPAjr8gOLU0xmChJimNP8r > o9RzphsO8O+mJMK0sdke9FEJByCgX3LbJYro21v0ZS0Nt2JW16Z8VakHNKfUbuLg > IYHbShHiEQ1GCWOQ+AIfpwG6td/NE/EhiCE9OixWAsvGq6e0w4k7vARG8hSfZDpp > 3hp7rD8x9EVp4v4e7G34Wr6FIZlfYzD2fX6SRu9wYpG/v87sgvrN9klY1YLn/zig > oZmOKJM5cC0iwnvHsavO > =4yFU > -----END PGP SIGNATURE----- > > -- > E-commerce Simplified! > https://youtu.be/GPPqvw8iEBs > https://goo.gl/Fho5Nq > Jonas Eklundh Unlike the intelligent people in political groups, Rick C. Hodgin relies on false news to blindly inform opinions on subjects. Ergo, he only is aware of and consents to the accepted claims which also are the ones which characterize free thought in a dishonestly approving and brave view. Hint: You will not go into a meet and greet, drink all the hooch, bang all the boys, rob the wallets, and throw up in the bedroom without being noticed. Can you stop begging for my attention? BTW, I've already discussed that his use of "herd" to describe COLA denizens is argumentum ad hominem, since he's likening them to beef cattle. - Get Rich Slow!! https://youtu.be/UkAyrfOZaXc https://youtu.be/m37dF5X2S-4 Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-01 12:31 -0800 |
| Message-ID | <289a1642-0378-4841-a3c3-ed32c1c2fd3f@googlegroups.com> |
| In reply to | #127189 |
On Thursday, March 1, 2018 at 1:22:39 PM UTC-6, Keith Thompson wrote: > supercat@casperkitty.com writes: > [...] > > Also, as a general matter of philosophy, if most platforms could practically > > support a behavior, and there any significant quantity of code would benefit > > from it, what disadvantage would there be to defining the behavior for all > > implementations that do not pre-define macro STDC_NO_whatever, but not > > imposing any requirements on implementations that do define that macro? > > Clutter. > > How many such behaviors should the standard define? How many > optional __STD_NO_whatever__ macros would have to be predefined? > By how many pages would the standard have to expand in order to > define the semantics of all these optional features? Not very many. Less than it spends on many other things of marginal usefulness. The behaviors in question are *not* complicated. From a practical perspective, there probably wouldn't be much need to have super-fine-grained control, except for one problem: lumping multiple behaviors under one macro would tend to imply judgment about what features should be supported by implementations or required by programs. By contrast, if the Standard says that an implementation must either behave a certain way or define a macro saying it does not, such a requirement would not imply any judgment as to whether a particular feature should be supported by a quality implementation or demanded by a quality program in any particular case. If a compiler declines to implement a feature and nobody notices, great. If a compiler declines to implement a feature and is thus unable to run many programs that people want to use, that would imply that if the feature should probably be implemented if practical. A compiler for a typical platform with optimization disabled would have no difficulty supporting nearly all of the behaviors I've described. Indeed, a compiler that supported many of the behaviors 100% of the time could often be simpler than one which would ever fail to do so. So as a lower bound, one could get by with one flag that simply said whether an implementation behaves in a fashion consistent with a typical microcomputer compiler that has all optimizations disabled, and a very wide range of tasks could be accomplished with completely-defined behaviors on many platforms without need for any features not described in the Standard.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-03-01 13:15 -0800 |
| Message-ID | <ln8tbbh50b.fsf@kst-u.example.com> |
| In reply to | #127196 |
supercat@casperkitty.com writes:
> On Thursday, March 1, 2018 at 1:22:39 PM UTC-6, Keith Thompson wrote:
>> supercat@casperkitty.com writes:
>> [...]
>> > Also, as a general matter of philosophy, if most platforms could practically
>> > support a behavior, and there any significant quantity of code would benefit
>> > from it, what disadvantage would there be to defining the behavior for all
>> > implementations that do not pre-define macro STDC_NO_whatever, but not
>> > imposing any requirements on implementations that do define that macro?
>>
>> Clutter.
>>
>> How many such behaviors should the standard define? How many
>> optional __STD_NO_whatever__ macros would have to be predefined?
>> By how many pages would the standard have to expand in order to
>> define the semantics of all these optional features?
>
> Not very many. Less than it spends on many other things of marginal
> usefulness. The behaviors in question are *not* complicated.
Good. Document them.
As you've seen, most people here, rightly or wrongly, do not agree with
your vision of what the standard should be.
Are you interested in proposing changes to the standard? Then do so.
Nobody else is going to do the work of gathering your suggestions into a
coherent document.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-03-01 14:55 -0800 |
| Message-ID | <96d97946-0c3b-4450-8c66-0630d7a113be@googlegroups.com> |
| In reply to | #127199 |
On Thursday, March 1, 2018 at 2:15:28 PM UTC-7, Keith Thompson wrote: > supercat@casperkitty.com writes: > > On Thursday, March 1, 2018 at 1:22:39 PM UTC-6, Keith Thompson wrote: > >> supercat@casperkitty.com writes: > >> [...] > >> > Also, as a general matter of philosophy, if most platforms could practically > >> > support a behavior, and there any significant quantity of code would benefit > >> > from it, what disadvantage would there be to defining the behavior for all > >> > implementations that do not pre-define macro STDC_NO_whatever, but not > >> > imposing any requirements on implementations that do define that macro? > >> > >> Clutter. > >> > >> How many such behaviors should the standard define? How many > >> optional __STD_NO_whatever__ macros would have to be predefined? > >> By how many pages would the standard have to expand in order to > >> define the semantics of all these optional features? > > > > Not very many. Less than it spends on many other things of marginal > > usefulness. The behaviors in question are *not* complicated. > > Good. Document them. > > As you've seen, most people here, rightly or wrongly, do not agree with > your vision of what the standard should be. > > Are you interested in proposing changes to the standard? Then do so. > Nobody else is going to do the work of gathering your suggestions into a > coherent document. > > [...] > > -- > Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> > Working, but not speaking, for JetHead Development, Inc. > "We must do something. This is something. Therefore, we must do this." > -- Antony Jay and Jonathan Lynn, "Yes Minister" Oh goodness, that is just tons of hooey. LOL! Right, Audra 'Super Troll' Moore is looking to produce a DOM variable, which anyone can get in 5 seconds, that anyone can learn from a video. If he wasn't so slow he'd get how screwed up he looks. This forum is a puss-filled cyst. - My Snoring Solution http://tinyurl.com/kmqe66h http://www.5z8.info/-php-deactivate_phishing_filter-48-_e3m8dt_malicious-cookie http://www.5z8.info/boobs_j0v3qo_dont-just-drizzle Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-03-03 02:19 -0800 |
| Message-ID | <kfnlgf9qx5c.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #127171 |
> Stop "suggesting", and try thinking. Now there is an ironic suggestion.
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web