Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #127213 > unrolled thread
| Started by | supercat@casperkitty.com |
|---|---|
| First post | 2018-03-01 16:38 -0800 |
| Last post | 2018-03-26 23:04 -0700 |
| Articles | 20 on this page of 150 — 11 participants |
Back to article view | Back to comp.lang.c
lvalue types supercat@casperkitty.com - 2018-03-01 16:38 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 17:17 -0800
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-01 17:37 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 22:00 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 23:49 -0800
Re: lvalue types asetofsymbols@gmail.com - 2018-03-05 06:56 -0800
Re: lvalue types supercat@casperkitty.com - 2018-03-02 00:22 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 01:23 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 05:04 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 06:06 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 08:12 -0800
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-02 09:50 -0800
Re: lvalue types supercat@casperkitty.com - 2018-03-02 11:33 -0800
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-02 11:45 -0800
Re: lvalue types supercat@casperkitty.com - 2018-03-02 16:28 -0800
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-02 16:54 -0800
Re: lvalue types supercat@casperkitty.com - 2018-03-02 17:50 -0800
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-02 19:43 -0800
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-02 22:51 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 23:07 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 01:44 -0800
Re: lvalue types supercat@casperkitty.com - 2018-03-03 13:01 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 22:21 -0800
Re: lvalue types supercat@casperkitty.com - 2018-03-02 09:24 -0800
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-03 00:58 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 01:13 -0800
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-03 13:01 -0800
Re: lvalue types supercat <flatfinger@casperkitty.com> - 2018-03-03 17:43 -0800
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-04 02:22 -0800
Re: lvalue types supercat@casperkitty.com - 2018-03-04 13:03 -0800
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-04 13:03 -0800
Re: lvalue types bartc <bc@freeuk.com> - 2018-03-04 22:32 +0000
Re: lvalue types supercat@casperkitty.com - 2018-03-05 09:45 -0800
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-19 09:54 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-19 11:52 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-26 23:44 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-27 09:14 -0700
Re: lvalue types supercat@casperkitty.com - 2018-03-27 12:21 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-28 17:01 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-29 01:54 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-30 08:32 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-30 09:25 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-03-30 10:58 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-31 00:52 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-02 15:19 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-03 10:06 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-03 11:33 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-03 12:19 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-03 12:48 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-05 10:17 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-05 10:52 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-05 12:39 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-06 06:13 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-04 16:38 -0700
Re: lvalue types supercat@casperkitty.com - 2018-03-27 12:09 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-28 10:48 -0700
Re: lvalue types supercat@casperkitty.com - 2018-03-19 12:27 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-03 14:02 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-04 17:32 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-04 20:24 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-09 08:31 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-11 11:19 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-11 12:44 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-12 06:45 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-12 07:54 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-12 14:26 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-12 14:43 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-12 17:40 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-13 03:02 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-13 00:27 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-13 07:19 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-16 08:52 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-16 10:28 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-16 13:58 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-16 14:52 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-16 16:22 -0700
Re: lvalue types Richard Damon <Richard@Damon-Family.org> - 2018-04-16 21:51 -0400
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-16 19:42 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-16 21:30 -0700
Re: lvalue types Richard Damon <Richard@Damon-Family.org> - 2018-04-17 07:01 -0400
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-17 04:22 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-19 02:43 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-17 07:25 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-17 08:48 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-17 09:54 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-17 10:37 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-17 11:00 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-17 11:48 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-17 12:45 -0700
Re: lvalue types scott@slp53.sl.home (Scott Lurndal) - 2018-04-17 19:55 +0000
Re: lvalue types jameskuyper@verizon.net - 2018-04-17 13:13 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-17 14:00 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-17 19:45 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 08:27 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-18 09:12 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 10:13 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-18 11:01 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-18 11:51 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 12:15 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-18 12:30 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 13:25 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-19 10:51 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-18 12:38 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 14:39 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-18 21:17 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-19 02:40 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-19 03:01 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-19 06:49 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-19 07:58 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-20 08:19 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-19 12:17 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-19 12:51 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-19 13:37 -0700
Re: lvalue types scott@slp53.sl.home (Scott Lurndal) - 2018-04-19 21:08 +0000
Re: lvalue types supercat@casperkitty.com - 2018-04-19 14:50 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-19 14:56 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-19 16:13 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-21 10:27 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-23 11:37 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-18 16:07 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-18 09:20 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 11:25 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-17 14:13 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-17 15:05 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-17 19:57 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 08:43 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-18 09:36 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-17 11:37 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-17 20:23 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 09:23 -0700
Re: lvalue types scott@slp53.sl.home (Scott Lurndal) - 2018-04-18 17:29 +0000
Re: lvalue types supercat@casperkitty.com - 2018-04-18 10:47 -0700
Re: lvalue types bartc <bc@freeuk.com> - 2018-04-18 20:04 +0100
Re: lvalue types jameskuyper@verizon.net - 2018-04-18 10:48 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 13:23 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-18 14:26 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 15:36 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-19 10:39 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-19 12:42 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-16 21:29 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-23 11:39 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-06-14 02:53 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-04 21:30 -0700
Re: lvalue types supercat@casperkitty.com - 2018-03-03 14:19 -0800
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 18:03 -0800
Re: lvalue types John Bode <jfbode1029@gmail.com> - 2018-03-21 10:33 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-21 11:53 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-22 00:11 -0700
Re: lvalue types supercat@casperkitty.com - 2018-03-21 11:53 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-26 23:04 -0700
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-17 04:22 -0700 |
| Message-ID | <74628316-b759-492f-bbb5-9480f030f93e@googlegroups.com> |
| In reply to | #129317 |
On Tuesday, April 17, 2018 at 4:01:16 AM UTC-7, Richard Damon wrote: > On 4/16/18 10:42 PM, Keith Thompson wrote: > > Richard Damon <Richard@Damon-Family.org> writes: > >> On 4/16/18 7:22 PM, supercat@casperkitty.com wrote: > >>> That is *generally* true, but there are some notable exceptions such as > >>> 6.5p7. That paragraph primarily affects programs whose meaning would > >>> otherwise be unambiguously implied by implementations' specified storage > >>> formats. > >> > >> An you don't seem to understand that what this paragraph says (as > >> supported by the footnote) that this limitation defines what the > >> Standard enforces on an implementation. NOTHING in this statement says > >> that an implementation can't define other conditions or methods of > >> accesses and how they behave. > >> > >> Yes, this does say that, absent promises by the implementation, that a > >> naive expectation of what seems 'natural' for a processor will behave > >> the way you want if you don't follow those rules. Every implementation > >> that I know of allows for ways to tell the compiler "I'm playing tricks > >> here, please act 'dumb' and do just what I am saying". > >> > >> Yes, this says you DO need to read and understand the documentation (and > >> if still not sure ASK the implementer) to do this sort of trick. > > > > Except that *if* I'm reading 6.5p7 correctly (as it's written, as > > opposed to as it was almost certainly intended), then the behavior > > of `obj.m = 42;` is explicitly undefined, because it accesses the > > struct object `obj` by the value `obj.m`, which has type int. > > > > I have no doubt that the intent was for `obj.m = 42;` to be well > > defined, modifying the value of obj.m and therefore the value of obj. > > The modification of obj is not (intended to be) undefined behavior > > that every implementation happens to sensibly implement in the > > same way. It's behavior that is intended to be well defined, with > > no wiggle room, but the standard failed to specify it correctly. > > (Assume if you like that "obj" is a struct whose only member is > > "m", of type int, that obj has no padding bytes, and that int has > > no padding bits or trap representations.) > > > > (Yes, Tim, I'm still planning to respond to your earlier posts.) > > > > That may be a defect in the Standard, or maybe they thought that it was > obvious that an assignment to obj.m will (possible) change the value of > obj, but isn't considered (for this purpose) an access of obj, but only > of its sub-object. The one thing The Holy Ghost learned well is to work to humiliate Pascal Hambourg into false confession and if that doesn't work, troll-splain or quickly change the argument. Usenet is a sovereign convention based on virtue that The Holy Ghost lacks. I have a little script I use as well, but it's better than yours. So, yeah, I buy into my own fancy, fully knowing it's fake, because it makes me reconsider my program, improving it. Advertising is a wonderful thing and consumer ignorance is even better. Of course, the top thing that matters to The Holy Ghost is being "accurate", and if he can't have that he will do more research to actively kick Pascal Hambourg down, which is dumb as hell. You're like a pregnant woman hiding behind a very skinny tree. We all see you sitting there and just laugh at you. And you're so dumb you keep rejecting it. A constant, relentless, posting itch, while suffering from an empty mind - like gunky worm camp followers, and vigorously-greased ram, stuck in a mud hole for his own individual requirements. -- My Snoring Solution http://www.5z8.info/hateminorities_t7l3gt_linked-in-of-sex http://comp.os.linux.advocacy.narkive.com/711dskzA/steven-petruzzellis-admits-he-can-not-back-his-claims-about-snit Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-04-19 02:43 -0700 |
| Message-ID | <kfnmuxz5y64.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #129317 |
Richard Damon <Richard@Damon-Family.org> writes: > On 4/16/18 10:42 PM, Keith Thompson wrote: > >> Richard Damon <Richard@Damon-Family.org> writes: >> >>> On 4/16/18 7:22 PM, supercat@casperkitty.com wrote: >>> >>>> That is *generally* true, but there are some notable exceptions such as >>>> 6.5p7. That paragraph primarily affects programs whose meaning would >>>> otherwise be unambiguously implied by implementations' specified storage >>>> formats. >>> >>> An you don't seem to understand that what this paragraph says (as >>> supported by the footnote) that this limitation defines what the >>> Standard enforces on an implementation. NOTHING in this statement says >>> that an implementation can't define other conditions or methods of >>> accesses and how they behave. >>> >>> Yes, this does say that, absent promises by the implementation, that a >>> naive expectation of what seems 'natural' for a processor will behave >>> the way you want if you don't follow those rules. Every implementation >>> that I know of allows for ways to tell the compiler "I'm playing tricks >>> here, please act 'dumb' and do just what I am saying". >>> >>> Yes, this says you DO need to read and understand the documentation (and >>> if still not sure ASK the implementer) to do this sort of trick. >> >> Except that *if* I'm reading 6.5p7 correctly (as it's written, as >> opposed to as it was almost certainly intended), then the behavior >> of `obj.m = 42;` is explicitly undefined, because it accesses the >> struct object `obj` by the value `obj.m`, which has type int. >> >> I have no doubt that the intent was for `obj.m = 42;` to be well >> defined, modifying the value of obj.m and therefore the value of obj. >> The modification of obj is not (intended to be) undefined behavior >> that every implementation happens to sensibly implement in the >> same way. It's behavior that is intended to be well defined, with >> no wiggle room, but the standard failed to specify it correctly. >> (Assume if you like that "obj" is a struct whose only member is >> "m", of type int, that obj has no padding bytes, and that int has >> no padding bits or trap representations.) >> >> (Yes, Tim, I'm still planning to respond to your earlier posts.) > > That may be a defect in the Standard, or maybe they thought that it was > obvious that an assignment to obj.m will (possible) change the value of > obj, but isn't considered (for this purpose) an access of obj, but only > of its sub-object. That is more or less what I think is intended.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-17 07:25 -0700 |
| Message-ID | <c2d54052-e0c6-4eef-b7c6-ff9839664bc7@googlegroups.com> |
| In reply to | #129298 |
On Monday, April 16, 2018 at 8:51:31 PM UTC-5, Richard Damon wrote: > On 4/16/18 7:22 PM, supercat@casperkitty.com wrote: > > That is *generally* true, but there are some notable exceptions such as > > 6.5p7. That paragraph primarily affects programs whose meaning would > > otherwise be unambiguously implied by implementations' specified storage > > formats. > > An you don't seem to understand that what this paragraph says (as > supported by the footnote) that this limitation defines what the > Standard enforces on an implementation. NOTHING in this statement says > that an implementation can't define other conditions or methods of > accesses and how they behave. The paragraph, as written, makes any program that uses structures containing non-character members and doesn't jump through absurd hoops to do is not strictly conforming, even if it would otherwise (in the absence of that paragraph) be strictly conforming and there would be no ambiguity as to its meaning.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-04-17 08:48 -0700 |
| Message-ID | <lnzi21ltpy.fsf@kst-u.example.com> |
| In reply to | #129341 |
supercat@casperkitty.com writes:
> On Monday, April 16, 2018 at 8:51:31 PM UTC-5, Richard Damon wrote:
>> On 4/16/18 7:22 PM, supercat@casperkitty.com wrote:
>> > That is *generally* true, but there are some notable exceptions such as
>> > 6.5p7. That paragraph primarily affects programs whose meaning would
>> > otherwise be unambiguously implied by implementations' specified storage
>> > formats.
>>
>> An you don't seem to understand that what this paragraph says (as
>> supported by the footnote) that this limitation defines what the
>> Standard enforces on an implementation. NOTHING in this statement says
>> that an implementation can't define other conditions or methods of
>> accesses and how they behave.
>
> The paragraph, as written, makes any program that uses structures containing
> non-character members and doesn't jump through absurd hoops to do is not
> strictly conforming, even if it would otherwise (in the absence of that
> paragraph) be strictly conforming and there would be no ambiguity as to its
> meaning.
Strict conformance is not the point. The point is that, as written
(assuming my reading of the literal wording is correct), it causes
such programs to have undefined behavior, a much stronger statement.
This:
printf("%zu\n", sizeof (int));
cannot appear in a strictly conforming program, but its behavior is well
defined (and its output implementation-defined).
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-17 09:54 -0700 |
| Message-ID | <108b8472-481e-43b4-9988-2c7e4648449d@googlegroups.com> |
| In reply to | #129351 |
On Tuesday, April 17, 2018 at 10:48:35 AM UTC-5, Keith Thompson wrote:
> supercat@casperkitty.com writes:
> > The paragraph, as written, makes any program that uses structures containing
> > non-character members and doesn't jump through absurd hoops to do is not
> > strictly conforming, even if it would otherwise (in the absence of that
> > paragraph) be strictly conforming and there would be no ambiguity as to its
> > meaning.
>
> Strict conformance is not the point. The point is that, as written
> (assuming my reading of the literal wording is correct), it causes
> such programs to have undefined behavior, a much stronger statement.
>
> This:
> printf("%zu\n", sizeof (int));
> cannot appear in a strictly conforming program, but its behavior is well
> defined (and its output implementation-defined).
The Standard does not define any category of "portable" programs that are
not Strictly Conforming. On the other hand, since it does explicitly
say that any code which invokes UB is either non-portable or erroneous,
perhaps my objection should be that the Standard says that code which tries
to use non-character members of structs or unions in what should be the
obvious logical fashion is either non-portable or erroneous, and the fact
that implementations happen to behave sensibly even though they are not
required to do so doesn't change that.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-04-17 10:37 -0700 |
| Message-ID | <lnvacplooa.fsf@kst-u.example.com> |
| In reply to | #129353 |
supercat@casperkitty.com writes:
> On Tuesday, April 17, 2018 at 10:48:35 AM UTC-5, Keith Thompson wrote:
>> supercat@casperkitty.com writes:
>> > The paragraph, as written, makes any program that uses structures containing
>> > non-character members and doesn't jump through absurd hoops to do is not
>> > strictly conforming, even if it would otherwise (in the absence of that
>> > paragraph) be strictly conforming and there would be no ambiguity as to its
>> > meaning.
>>
>> Strict conformance is not the point. The point is that, as written
>> (assuming my reading of the literal wording is correct), it causes
>> such programs to have undefined behavior, a much stronger statement.
>>
>> This:
>> printf("%zu\n", sizeof (int));
>> cannot appear in a strictly conforming program, but its behavior is well
>> defined (and its output implementation-defined).
>
> The Standard does not define any category of "portable" programs that are
> not Strictly Conforming. On the other hand, since it does explicitly
> say that any code which invokes UB is either non-portable or erroneous,
> perhaps my objection should be that the Standard says that code which tries
> to use non-character members of structs or unions in what should be the
> obvious logical fashion is either non-portable or erroneous, and the fact
> that implementations happen to behave sensibly even though they are not
> required to do so doesn't change that.
Or you could just say that the standard as currently written says
the behavior is undefined (because it violates a "shall" outside
a constraint), and save us all a lot of time.
I fail to see the point of going off on a tangent about categories of
"portable" programs.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-17 11:00 -0700 |
| Message-ID | <2bf95ece-0d26-49aa-8629-87d9c47ef2ad@googlegroups.com> |
| In reply to | #129354 |
On Tuesday, April 17, 2018 at 12:37:34 PM UTC-5, Keith Thompson wrote: > Or you could just say that the standard as currently written says > the behavior is undefined (because it violates a "shall" outside > a constraint), and save us all a lot of time. > > I fail to see the point of going off on a tangent about categories of > "portable" programs. Many people claim there's no particular need to have the Standard define certain things because implementations can do so whether or not the Standard does. If the Standard is supposed to facilitate the writing of portable programs, having the standard needlessly characterize common constructs as "non-portable" undercuts that goal.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-04-17 11:48 -0700 |
| Message-ID | <lnmuy1lldy.fsf@kst-u.example.com> |
| In reply to | #129356 |
supercat@casperkitty.com writes:
> On Tuesday, April 17, 2018 at 12:37:34 PM UTC-5, Keith Thompson wrote:
>> Or you could just say that the standard as currently written says
>> the behavior is undefined (because it violates a "shall" outside
>> a constraint), and save us all a lot of time.
>>
>> I fail to see the point of going off on a tangent about categories of
>> "portable" programs.
>
> Many people claim there's no particular need to have the Standard define
> certain things because implementations can do so whether or not the
> Standard does. If the Standard is supposed to facilitate the writing of
> portable programs, having the standard needlessly characterize common
> constructs as "non-portable" undercuts that goal.
That's not what we're talking about here.
Nobody is saying that there's no need for the standard to define the
behavior of `obj.m = 42;`. Either the standard *unintentionally* fails
to define the behavior and that's a flaw that needs to be corrected, or
the standard does define it.
"It's ok not to define the behavior of `obj.m = 42;`" is not
something that anyone has claimed explicitly or implicitly.
If that's the claim you're arguing against, you win.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-17 12:45 -0700 |
| Message-ID | <97b9de3e-f3f8-45c1-8850-a29ca57069d5@googlegroups.com> |
| In reply to | #129358 |
On Tuesday, April 17, 2018 at 1:48:34 PM UTC-5, Keith Thompson wrote: > supercat@casperkitty.com writes: > > On Tuesday, April 17, 2018 at 12:37:34 PM UTC-5, Keith Thompson wrote: > >> Or you could just say that the standard as currently written says > >> the behavior is undefined (because it violates a "shall" outside > >> a constraint), and save us all a lot of time. > >> > >> I fail to see the point of going off on a tangent about categories of > >> "portable" programs. > > > > Many people claim there's no particular need to have the Standard define > > certain things because implementations can do so whether or not the > > Standard does. If the Standard is supposed to facilitate the writing of > > portable programs, having the standard needlessly characterize common > > constructs as "non-portable" undercuts that goal. > > That's not what we're talking about here. > > Nobody is saying that there's no need for the standard to define the > behavior of `obj.m = 42;`. Either the standard *unintentionally* fails > to define the behavior and that's a flaw that needs to be corrected, or > the standard does define it. > > "It's ok not to define the behavior of `obj.m = 42;`" is not > something that anyone has claimed explicitly or implicitly. > > If that's the claim you're arguing against, you win. It was apparent even in 1992 that the Standard failed to adequately specify the cases where a union object may be accessed using a pointer to a member. Had it done so, the answer to DR028 would have been obvious. Between 1992 and 1999, the lack of clarity might have been reasonably regarded as an oversight. Do you think the failure to address the issue in not just one but two subsequent revisions of the Standard continues to be a result of mere oversight?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-04-17 19:55 +0000 |
| Message-ID | <cjsBC.2220$Hv4.969@fx39.iad> |
| In reply to | #129359 |
supercat@casperkitty.com writes: >On Tuesday, April 17, 2018 at 1:48:34 PM UTC-5, Keith Thompson wrote: >> supercat@casperkitty.com writes: >> > On Tuesday, April 17, 2018 at 12:37:34 PM UTC-5, Keith Thompson wrote: >> >> Or you could just say that the standard as currently written says >> >> the behavior is undefined (because it violates a "shall" outside >> >> a constraint), and save us all a lot of time. >> >> >> >> I fail to see the point of going off on a tangent about categories of >> >> "portable" programs. >> > >> > Many people claim there's no particular need to have the Standard define >> > certain things because implementations can do so whether or not the >> > Standard does. If the Standard is supposed to facilitate the writing of >> > portable programs, having the standard needlessly characterize common >> > constructs as "non-portable" undercuts that goal. >> >> That's not what we're talking about here. >> >> Nobody is saying that there's no need for the standard to define the >> behavior of `obj.m = 42;`. Either the standard *unintentionally* fails >> to define the behavior and that's a flaw that needs to be corrected, or >> the standard does define it. >> >> "It's ok not to define the behavior of `obj.m = 42;`" is not >> something that anyone has claimed explicitly or implicitly. >> >> If that's the claim you're arguing against, you win. > >It was apparent even in 1992 that the Standard failed to adequately specify One seriously wonders how so many thousands of C programers have written so many millions of portable C applications since 1989 with such a flawed standard. Or perhaps, just perhaps, you're being quixotic.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2018-04-17 13:13 -0700 |
| Message-ID | <0411fdf5-9ca7-48b2-b7d8-23dd874e95d9@googlegroups.com> |
| In reply to | #129359 |
On Tuesday, April 17, 2018 at 3:46:07 PM UTC-4, supe...@casperkitty.com wrote: > On Tuesday, April 17, 2018 at 1:48:34 PM UTC-5, Keith Thompson wrote: ... > > That's not what we're talking about here. > > > > Nobody is saying that there's no need for the standard to define the > > behavior of `obj.m = 42;`. Either the standard *unintentionally* fails > > to define the behavior and that's a flaw that needs to be corrected, or > > the standard does define it. > > > > "It's ok not to define the behavior of `obj.m = 42;`" is not > > something that anyone has claimed explicitly or implicitly. > > > > If that's the claim you're arguing against, you win. > > It was apparent even in 1992 that the Standard failed to adequately specify > the cases where a union object may be accessed using a pointer to a member. > Had it done so, the answer to DR028 would have been obvious. > > Between 1992 and 1999, the lack of clarity might have been reasonably > regarded as an oversight. Do you think the failure to address the issue > in not just one but two subsequent revisions of the Standard continues to > be a result of mere oversight? Do you honestly think the committee intentionally choose to make virtually every meaningful use of struct types undefined behavior?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-17 14:00 -0700 |
| Message-ID | <b83e7af9-fbf9-4eb0-8178-808e1df46075@googlegroups.com> |
| In reply to | #129361 |
On Tuesday, April 17, 2018 at 3:14:07 PM UTC-5, james...@verizon.net wrote: > Do you honestly think the committee intentionally choose to make virtually every meaningful use of struct types undefined behavior? From what I can tell, the Committee has effectively faced a three-way choice: 1. Recognize that taking the address of a member of a struct or union object yields a pointer that may be used to access the storage associated with that member, at least while all operations related to that storage are done exclusively with that pointer or others derived from it. 2. Recognize that applying the address-of operator of a member of a struct or union object and dereferencing it--even immediately--need not have any relationship to the act of using the member directly. 3. Treat the use of a pointer to a member as being equivalent to direct use of the member, without bothering to define either. Some members are so strongly opposed to #1 that they'd rather accept #3. Other members likewise oppose #2. I don't particularly think that there were any members who would prefer #3 to their own favorite alternative, but if about half of the Committee ranks the choices 2-3-1 and about half ranks them 1-3-2, the Committee as a whole will favor #3 over any other particular alternative.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2018-04-17 19:45 -0700 |
| Message-ID | <f0cc8e46-f957-44a6-a6f0-b96697f33684@googlegroups.com> |
| In reply to | #129362 |
On Tuesday, April 17, 2018 at 5:00:23 PM UTC-4, supe...@casperkitty.com wrote: > On Tuesday, April 17, 2018 at 3:14:07 PM UTC-5, james...@verizon.net wrote: > > Do you honestly think the committee intentionally choose to make virtually every meaningful use of struct types undefined behavior? > > From what I can tell, the Committee has effectively faced a three-way choice: > > 1. Recognize that taking the address of a member of a struct or union object > yields a pointer that may be used to access the storage associated with > that member, at least while all operations related to that storage are > done exclusively with that pointer or others derived from it. Taking 6.5p7 as actually written, ignoring the fact that it's clearly inconsistent with anything the committee could reasonably have intend to say, then direct use of a member of a struct is just as much undefined behavior as dereferencing apointer to that member. That's because 6.5p7 is worded solely in terms of lvalues, and dereferencing a pointer to a member or referring directly to a member of a struct are two equally valid ways of creating lvalues that refer to the member. Therefore, I don't see how the distinction you're making between dereferencing a pointer and direct use of a member is relevant to this issue. > 2. Recognize that applying the address-of operator of a member of a struct > or union object and dereferencing it--even immediately--need not have any > relationship to the act of using the member directly. > > 3. Treat the use of a pointer to a member as being equivalent to direct > use of the member, without bothering to define either. To the best of my understanding, I would expect essentially all of the committee members to see nothing objectionable with #1, and nothing worthwhile about #2 or #3. What, if anything, has given you the belief that there is any significant number of people on the committee who disagree with #1, or who agree with #2 or #3?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-18 08:27 -0700 |
| Message-ID | <bd5137e0-47d1-4555-9773-12b853f751f6@googlegroups.com> |
| In reply to | #129375 |
On Tuesday, April 17, 2018 at 9:45:47 PM UTC-5, james...@verizon.net wrote:
> Taking 6.5p7 as actually written, ignoring the fact that it's clearly
> inconsistent with anything the committee could reasonably have intend to
> say, then direct use of a member of a struct is just as much undefined
> behavior as dereferencing apointer to that member. That's because 6.5p7
> is worded solely in terms of lvalues, and dereferencing a pointer to a
> member or referring directly to a member of a struct are two equally
> valid ways of creating lvalues that refer to the member. Therefore, I
> don't see how the distinction you're making between dereferencing a
> pointer and direct use of a member is relevant to this issue.
The ability to pass the address of an object to functions that can use
the object, at least until the next time the object is addressed via other
means, is no less fundamental than the ability to use the structure
directly. Both clang and gcc, however, *invent* a distinction between
direct and indirect use of objects.
[from above]
>> 1. Recognize that taking the address of a member of a struct or union object
>> yields a pointer that may be used to access the storage associated with
>> that member, at least while all operations related to that storage are
>> done exclusively with that pointer or others derived from it.
>> 2. Recognize that applying the address-of operator of a member of a struct
>> or union object and dereferencing it--even immediately--need not have any
>> relationship to the act of using the member directly.
>>
>> 3. Treat the use of a pointer to a member as being equivalent to direct
>> use of the member, without bothering to define either.
>
> To the best of my understanding, I would expect essentially all of the
> committee members to see nothing objectionable with #1, and nothing
> worthwhile about #2 or #3. What, if anything, has given you the belief
> that there is any significant number of people on the committee who
> disagree with #1, or who agree with #2 or #3?
Both gcc and clang are heavily invested in a design that can't reliably
handle #1. I don't think any of the Committee members would have opposed
codifying #1 back in 1989, but I think the maintainers of gcc and clang
have enough clout to block it today.
Given something like:
T *p;
p = &unionArr[i].member;
...
p = &unionArr[i].member;
each statement actually needs to do two things:
1. Compute the address of the member and "store" it into 'p' [the
value could be stored in a register].
2. Associate the pointer with the object, so that any use of the pointer
will follow any use of the original object or any pointer that was
previously derived from it in the same context, and precede the next
succeeding use of the original object to access the same storage or
derive another pointer that will be used to do so.
If nothing changes 'i' nor 'p' between the two statements, the second
address computation and store to 'p' may be safely omitted. From what
I can tell, however, both gcc and clang rely upon computations and
accesses to create associations between objects that might use the same
storage. If those accesses and computations vanish as a result of
optimizations, the associations do as well.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-04-18 09:12 -0700 |
| Message-ID | <lnefjclci2.fsf@kst-u.example.com> |
| In reply to | #129405 |
supercat@casperkitty.com writes:
[...]
> The ability to pass the address of an object to functions that can use
> the object, at least until the next time the object is addressed via other
> means, is no less fundamental than the ability to use the structure
> directly. Both clang and gcc, however, *invent* a distinction between
> direct and indirect use of objects.
I'm probably going to regret asking this, but can you support the
claim in your last sentence? (I request that you do so without
asking rhetorical questions.)
[...]
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-18 10:13 -0700 |
| Message-ID | <fd77df70-1361-4c60-8214-f4e74059281c@googlegroups.com> |
| In reply to | #129408 |
On Wednesday, April 18, 2018 at 11:12:49 AM UTC-5, Keith Thompson wrote:
> supercat@casperkitty.com writes:
> [...]
> > The ability to pass the address of an object to functions that can use
> > the object, at least until the next time the object is addressed via other
> > means, is no less fundamental than the ability to use the structure
> > directly. Both clang and gcc, however, *invent* a distinction between
> > direct and indirect use of objects.
>
> I'm probably going to regret asking this, but can you support the
> claim in your last sentence? (I request that you do so without
> asking rhetorical questions.)
I've posted code many times where both gcc and clang create such a
distinction.
struct s1 { int x; };
struct s2 { int x; };
union u { struct s1 v1; struct s2 v2; } uarr[10];
int readS1x(struct s1 *p) { return p->x; }
void writeS2x(struct s2 *p) { p->x = 5; }
int test(union u *uarr2, int i, int j)
{
if (readS1x(&uarr[i].v1))
writeS2x(&uarr[j].v2);
return readS1x(&uarr[i].v1);
}
Both gcc and clang will assume that there's no way an operation on a struct
s2 can affect a struct s1, even if all operations on the storage using
different types are separated by actions which derive pointers of those
types from the same lvalue "uarr".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-04-18 11:01 -0700 |
| Message-ID | <ln604ol7fu.fsf@kst-u.example.com> |
| In reply to | #129414 |
supercat@casperkitty.com writes:
> On Wednesday, April 18, 2018 at 11:12:49 AM UTC-5, Keith Thompson wrote:
>> supercat@casperkitty.com writes:
>> [...]
>> > The ability to pass the address of an object to functions that can use
>> > the object, at least until the next time the object is addressed via other
>> > means, is no less fundamental than the ability to use the structure
>> > directly. Both clang and gcc, however, *invent* a distinction between
>> > direct and indirect use of objects.
>>
>> I'm probably going to regret asking this, but can you support the
>> claim in your last sentence? (I request that you do so without
>> asking rhetorical questions.)
>
> I've posted code many times where both gcc and clang create such a
> distinction.
>
> struct s1 { int x; };
> struct s2 { int x; };
> union u { struct s1 v1; struct s2 v2; } uarr[10];
>
> int readS1x(struct s1 *p) { return p->x; }
> void writeS2x(struct s2 *p) { p->x = 5; }
>
> int test(union u *uarr2, int i, int j)
> {
> if (readS1x(&uarr[i].v1))
> writeS2x(&uarr[j].v2);
> return readS1x(&uarr[i].v1);
> }
>
> Both gcc and clang will assume that there's no way an operation on a struct
> s2 can affect a struct s1, even if all operations on the storage using
> different types are separated by actions which derive pointers of those
> types from the same lvalue "uarr".
Can you substantiate your claim about what assumptions gcc and
clang make, by showing us a self-contained program whose output
clearly demonstrates those assumptions?
--
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 | jameskuyper@verizon.net |
|---|---|
| Date | 2018-04-18 11:51 -0700 |
| Message-ID | <565bbda5-9ae0-407f-a429-6bc683471336@googlegroups.com> |
| In reply to | #129414 |
On Wednesday, April 18, 2018 at 1:13:36 PM UTC-4, supe...@casperkitty.com wrote:
> On Wednesday, April 18, 2018 at 11:12:49 AM UTC-5, Keith Thompson wrote:
> > supercat@casperkitty.com writes:
> > [...]
> > > The ability to pass the address of an object to functions that can use
> > > the object, at least until the next time the object is addressed via other
> > > means, is no less fundamental than the ability to use the structure
> > > directly. Both clang and gcc, however, *invent* a distinction between
> > > direct and indirect use of objects.
> >
> > I'm probably going to regret asking this, but can you support the
> > claim in your last sentence? (I request that you do so without
> > asking rhetorical questions.)
>
> I've posted code many times where both gcc and clang create such a
> distinction.
Could you provide Google Groups message links to identify previous occasions when you discussed such code? I don't want to waste time on side issues that have already been taken care of in the previous discussions.
> struct s1 { int x; };
> struct s2 { int x; };
> union u { struct s1 v1; struct s2 v2; } uarr[10];
>
> int readS1x(struct s1 *p) { return p->x; }
> void writeS2x(struct s2 *p) { p->x = 5; }
>
> int test(union u *uarr2, int i, int j)
> {
> if (readS1x(&uarr[i].v1))
> writeS2x(&uarr[j].v2);
> return readS1x(&uarr[i].v1);
Why does test() have a parameter named uarr2, which it makes no use of?
> }
>
> Both gcc and clang will assume that there's no way an operation on a struct
> s2 can affect a struct s1, even if all operations on the storage using
> different types are separated by actions which derive pointers of those
> types from the same lvalue "uarr".
That's a start. Now could you provide us with a test harness that
demonstrates the problem? I wrote a simple test drive that didn't
display any obvious problems, so apparently my test driver didn't
trigger the problematic case.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-18 12:15 -0700 |
| Message-ID | <4a251381-b49c-4629-8495-15f0fd7ea94b@googlegroups.com> |
| In reply to | #129422 |
On Wednesday, April 18, 2018 at 1:51:48 PM UTC-5, james...@verizon.net wrote:
> On Wednesday, April 18, 2018 at 1:13:36 PM UTC-4, supe...@casperkitty.com wrote:
> > On Wednesday, April 18, 2018 at 11:12:49 AM UTC-5, Keith Thompson wrote:
> > > supercat@casperkitty.com writes:
> > > [...]
> > > > The ability to pass the address of an object to functions that can use
> > > > the object, at least until the next time the object is addressed via other
> > > > means, is no less fundamental than the ability to use the structure
> > > > directly. Both clang and gcc, however, *invent* a distinction between
> > > > direct and indirect use of objects.
> > >
> > > I'm probably going to regret asking this, but can you support the
> > > claim in your last sentence? (I request that you do so without
> > > asking rhetorical questions.)
> >
> > I've posted code many times where both gcc and clang create such a
> > distinction.
>
> Could you provide Google Groups message links to identify previous occasions when you discussed such code? I don't want to waste time on side issues that have already been taken care of in the previous discussions.
>
> > struct s1 { int x; };
> > struct s2 { int x; };
> > union u { struct s1 v1; struct s2 v2; } uarr[10];
> >
> > int readS1x(struct s1 *p) { return p->x; }
> > void writeS2x(struct s2 *p) { p->x = 5; }
> >
> > int test(union u *uarr2, int i, int j)
> > {
> > if (readS1x(&uarr[i].v1))
> > writeS2x(&uarr[j].v2);
> > return readS1x(&uarr[i].v1);
> > }
>
> Why does test() have a parameter named uarr2, which it makes no use of?
Oops--I'd been adjusting the code to experiment some with what things
gcc would and would not notice, and forgot to roll back that change.
> > Both gcc and clang will assume that there's no way an operation on a struct
> > s2 can affect a struct s1, even if all operations on the storage using
> > different types are separated by actions which derive pointers of those
> > types from the same lvalue "uarr".
>
> That's a start. Now could you provide us with a test harness that
> demonstrates the problem? I wrote a simple test drive that didn't
> display any obvious problems, so apparently my test driver didn't
> trigger the problematic case.
struct s1 { int x; };
struct s2 { int x; };
union u { struct s1 v1; struct s2 v2; } uarr[10];
static int readS1x(struct s1 *p) { return p->x; }
static void writeS2x(struct s2 *p) { p->x = 5; }
int test(int i, int j)
{
if (readS1x(&uarr[i].v1))
writeS2x(&uarr[j].v2);
return readS1x(&uarr[i].v1);
}
int (*volatile vtest)(int,int) = test;
#include <stdio.h>
volatile int result;
int main(void)
{
uarr[0].v2.x = 1;
result = vtest(0,0);
printf("Result=%d", result);
}
The generated code for "test" [gcc 7.3] is:
test:
movsx rdi, edi
mov eax, DWORD PTR uarr[0+rdi*4]
test eax, eax
je .L1
movsx rsi, esi
mov DWORD PTR uarr[0+rsi*4], 5
.L1:
rep ret
.LC0:
.string "Result=%d"
which is equivalent to:
int test(int i, int j) //test:
{ long rdi = i; // movsx rdi, edi
int eax = uarr[rdi].v1.x; // mov eax, DWORD PTR uarr[0+rdi*4]
if (!eax) // test eax, eax
goto L1; // je .L1
long rsi = j; // movsx rsi, esi
uarr[rsi].v2.x = 5; // mov DWORD PTR uarr[0+rsi*4], 5
L1: // .L1:
return eax; //
}
If test() isn't called through a "volatile" pointer, the compiler sometimes
figures out while in-lining it that uarr[i] and uarr[j] might be related,
but the standalone machine code for "test" is exactly as above.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2018-04-18 12:30 -0700 |
| Message-ID | <493e0100-1ae1-4947-8383-d7a6b2fc453e@googlegroups.com> |
| In reply to | #129424 |
On Wednesday, April 18, 2018 at 3:15:35 PM UTC-4, supe...@casperkitty.com wrote:
> On Wednesday, April 18, 2018 at 1:51:48 PM UTC-5, james...@verizon.net wrote:
> > On Wednesday, April 18, 2018 at 1:13:36 PM UTC-4, supe...@casperkitty.com wrote:
...
> > > I've posted code many times where both gcc and clang create such a
> > > distinction.
> >
> > Could you provide Google Groups message links to identify previous
> > occasions when you discussed such code? I don't want to waste time on side
> > issues that have already been taken care of in the previous discussions.
You ignored that request.
...
> > That's a start. Now could you provide us with a test harness that
> > demonstrates the problem? I wrote a simple test drive that didn't
> > display any obvious problems, so apparently my test driver didn't
> > trigger the problematic case.
>
> struct s1 { int x; };
> struct s2 { int x; };
> union u { struct s1 v1; struct s2 v2; } uarr[10];
>
> static int readS1x(struct s1 *p) { return p->x; }
> static void writeS2x(struct s2 *p) { p->x = 5; }
> int test(int i, int j)
> {
> if (readS1x(&uarr[i].v1))
> writeS2x(&uarr[j].v2);
> return readS1x(&uarr[i].v1);
> }
>
> int (*volatile vtest)(int,int) = test;
>
> #include <stdio.h>
> volatile int result;
> int main(void)
> {
> uarr[0].v2.x = 1;
> result = vtest(0,0);
> printf("Result=%d", result);
> }
>
> The generated code for "test" [gcc 7.3] is:
I didn't ask for disassembled output displaying what you think is a problem. I don't have enough recent assembler experience to make an expert judgement about such code. I asked you for example code whose behavior demonstrates the problem you're talking about.
I added "static" to test(), and "return 0;" to main(), and "\n" to the printf() format string. After those corrections, it compiled an executed to produce the following output:
Result=5
Which is, as I understand it, precisely what it's supposed to produce.
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web