Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #29771 > unrolled thread
| Started by | Maciej Labanowicz <m.labanowicz@gmail.com> |
|---|---|
| First post | 2013-01-01 03:45 -0800 |
| Last post | 2013-01-02 10:34 -0800 |
| Articles | 20 on this page of 107 — 11 participants |
Back to article view | Back to comp.lang.c
[union] Pointers to inherited structs are valid ? Maciej Labanowicz <m.labanowicz@gmail.com> - 2013-01-01 03:45 -0800
Re: [union] Pointers to inherited structs are valid ? Barry Schwarz <schwarzb@dqel.com> - 2013-01-01 17:59 -0800
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-02 10:18 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-01 21:06 -0500
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-02 10:45 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-02 19:56 -0500
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-03 08:28 -0500
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-03 15:31 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-03 20:55 -0500
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-03 21:00 -0500
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-04 12:56 -0500
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-04 12:59 -0500
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-06 20:00 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-07 00:47 -0500
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-06 23:06 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-07 04:03 -0500
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-07 08:25 -0500
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-13 10:34 -0800
Re: Off-Topic: Irritating Posting Patterns Shao Miller <sha0.miller@gmail.com> - 2013-01-13 16:00 -0500
Re: Off-Topic: Irritating Posting Patterns Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-14 12:27 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-07 07:41 -0500
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-12 14:52 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-13 15:19 -0500
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-14 12:04 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-14 18:52 -0500
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-16 00:01 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-16 05:43 -0500
Re: [union] Pointers to inherited structs are valid ? Geoff <geoff@invalid.invalid> - 2013-01-16 09:01 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-16 18:32 -0500
Re: [union] Pointers to inherited structs are valid ? Geoff <geoff@invalid.invalid> - 2013-01-16 17:32 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-16 20:57 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-17 07:55 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-17 16:47 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-18 08:41 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-18 15:53 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-18 17:38 -0800
Re: [union] Pointers to inherited structs are valid ? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-19 02:31 +0000
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-18 23:15 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-19 20:03 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-20 02:19 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-20 07:57 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-20 15:25 -0500
Re: [union] Pointers to inherited structs are valid ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-20 23:58 +0000
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-20 21:30 -0500
Re: [union] Pointers to inherited structs are valid ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-21 02:53 +0000
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-21 00:05 -0500
Re: [union] Pointers to inherited structs are valid ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-21 16:31 +0000
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-21 14:07 -0500
Re: [union] Pointers to inherited structs are valid ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-21 21:05 +0000
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-21 17:13 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-21 16:11 -0800
Re: [union] Pointers to inherited structs are valid ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-22 04:59 +0000
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-22 01:05 -0500
Re: [union] Pointers to inherited structs are valid ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-22 14:53 +0000
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-22 08:38 -0800
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-21 20:53 -0800
Re: [union] Pointers to inherited structs are valid ? Philip Lantz <prl@canterey.us> - 2013-01-22 00:58 -0800
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-22 08:40 -0800
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-22 23:32 -0800
Re: [union] Pointers to inherited structs are valid ? Philip Lantz <prl@canterey.us> - 2013-01-23 23:21 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-24 04:53 -0500
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-25 10:49 -0800
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-22 08:25 -0800
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-22 23:41 -0800
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-21 13:32 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-21 17:46 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-22 07:43 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-22 16:07 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-22 14:15 -0800
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-22 14:31 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-22 21:32 -0500
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-23 17:17 -0500
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-23 19:49 -0500
Re: [union] Pointers to inherited structs are valid ? Geoff <geoff@invalid.invalid> - 2013-01-23 18:55 -0800
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-24 11:01 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-24 14:11 -0500
Re: [union] Pointers to inherited structs are valid ? Geoff <geoff@invalid.invalid> - 2013-01-22 17:51 -0800
Re: [union] Pointers to inherited structs are valid ? Philip Lantz <prl@canterey.us> - 2013-01-20 16:48 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-20 21:33 -0500
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-21 09:23 -0800
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-20 17:07 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-20 22:20 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-20 22:02 -0800
Re: [union] Pointers to inherited structs are valid ? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-21 07:00 +0000
Re: [union] Pointers to inherited structs are valid ? James Kuyper <jameskuyper@verizon.net> - 2013-01-21 08:17 -0500
Re: [union] Pointers to inherited structs are valid ? Dr Nick <nospam-4@temporary-address.org.uk> - 2013-01-21 14:13 +0000
Re: [union] Pointers to inherited structs are valid ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-21 14:12 +0000
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-21 08:20 -0800
Re: [union] Pointers to inherited structs are valid ? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-21 20:41 +0000
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-21 12:37 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-21 12:17 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-21 16:33 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-21 15:50 -0800
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-21 19:45 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-22 00:18 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-22 08:01 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-18 23:02 -0500
Re: [union] Pointers to inherited structs are valid ? Philip Lantz <prl@canterey.us> - 2013-01-19 01:28 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-19 12:08 -0500
Re: [union] Pointers to inherited structs are valid ? Geoff <geoff@invalid.invalid> - 2013-01-21 09:27 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-21 12:46 -0500
Re: [union] Pointers to inherited structs are valid ? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-21 20:48 +0000
Re: [union] Pointers to inherited structs are valid ? Geoff <geoff@invalid.invalid> - 2013-01-21 18:52 -0800
Re: [union] Pointers to inherited structs are valid ? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-22 04:07 +0000
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-21 23:15 -0500
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-16 10:59 -0800
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-02 10:34 -0800
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2013-01-07 07:41 -0500 |
| Message-ID | <kcefpr$kb1$1@dont-email.me> |
| In reply to | #29855 |
On 1/6/2013 23:00, Tim Rentsch wrote:
> Shao Miller <sha0.miller@gmail.com> writes:
>> Surely if, in
>>
>> void somefunc(void) {
>> unsigned char c;
>> /* ... */
>> }
>>
>> 'c' is permitted to have a trap representation due to its
>> "provenance,"
>
> It isn't. You are either mis-remembering or have misunderstood.
>
Committee Discussion in Defect Report #260:
"In addition the C Standard does not prohibit an implementation from
tracking the provenance of the bit-pattern representing a value. An
indeterminate value happening to have a bit pattern that is identical to
a bit pattern representing a determinate value is not sufficient to
allow access to the indeterminate value free from undefined behavior."
That suggests to me that real implementation representatives discussed
it, and some of them must have argued that there is more to object
representation and value than a simple mapping. I suggest that there
are other meta-considerations (such as "indeterminate value"), some of
which are crucial to an implementation that wishes to have "enforceable
coding rules":
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1663.pdf
'c' above is permitted to have a trap representation without even having
that fact coded into its object representation. If I've misunderstood,
then I apologize. If you have further knowledge of the status of DR
#260, then please share! :)
- Shao Miller
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2013-01-12 14:52 -0800 |
| Message-ID | <kfny5fy9fp5.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #29873 |
Shao Miller <sha0.miller@gmail.com> writes:
> On 1/6/2013 23:00, Tim Rentsch wrote:
>> Shao Miller <sha0.miller@gmail.com> writes:
>>> Surely if, in
>>>
>>> void somefunc(void) {
>>> unsigned char c;
>>> /* ... */
>>> }
>>>
>>> 'c' is permitted to have a trap representation due to its
>>> "provenance,"
>>
>> It isn't. You are either mis-remembering or have misunderstood.
>
> Committee Discussion in Defect Report #260: [snip]
The type unsigned char does not have trap representations. There
are no exceptions. Types that don't have trap representations
never have a trap representation.
In C11, accessing a variable like 'c' above before it has been
initialiized is undefined behavior. But that is because C11
added (relative to, eg, N1256) a specific statement regarding
such cases, stating explicitly that the behavior is undefined;
it has nothing to do with provenance or trap representations.
Indeed, seeing that this proviso was added in C11 makes it
obvious that DR 260 doesn't apply to cases like the example
above, because otherwise there would be no reason to add it.
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2013-01-13 15:19 -0500 |
| Message-ID | <kcv4rr$bcq$1@dont-email.me> |
| In reply to | #30037 |
On 1/12/2013 17:52, Tim Rentsch wrote:
> Shao Miller <sha0.miller@gmail.com> writes:
>
>> On 1/6/2013 23:00, Tim Rentsch wrote:
>>> Shao Miller <sha0.miller@gmail.com> writes:
>>>> Surely if, in
>>>>
>>>> void somefunc(void) {
>>>> unsigned char c;
>>>> /* ... */
>>>> }
>>>>
>>>> 'c' is permitted to have a trap representation due to its
>>>> "provenance,"
>>>
>>> It isn't. You are either mis-remembering or have misunderstood.
>>
>> Committee Discussion in Defect Report #260:
>>
>> "In addition the C Standard does not prohibit an implementation from
>> tracking the provenance of the bit-pattern representing a value. An
>> indeterminate value happening to have a bit pattern that is identical to
>> a bit pattern representing a determinate value is not sufficient to
>> allow access to the indeterminate value free from undefined behavior."
>>
>> That suggests to me that real implementation representatives discussed
>> it, and some of them must have argued that there is more to object
>> representation and value than a simple mapping. I suggest that there
>> are other meta-considerations (such as "indeterminate value"), some of
>> which are crucial to an implementation that wishes to have "enforceable
>> coding rules":
>>
>> http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1663.pdf
>>
>> 'c' above is permitted to have a trap representation without even having
>> that fact coded into its object representation. If I've misunderstood,
>> then I apologize. If you have further knowledge of the status of DR
>> #260, then please share! :)
>
> The type unsigned char does not have trap representations. There
> are no exceptions. Types that don't have trap representations
> never have a trap representation.
>
> In C11, accessing a variable like 'c' above before it has been
> initialiized is undefined behavior. But that is because C11
> added (relative to, eg, N1256) a specific statement regarding
> such cases, stating explicitly that the behavior is undefined;
> it has nothing to do with provenance or trap representations.
> Indeed, seeing that this proviso was added in C11 makes it
> obvious that DR 260 doesn't apply to cases like the example
> above, because otherwise there would be no reason to add it.
>
Now I think I understand what you are talking about, here. I think you
are discussing a trap representation as if it is associated with a type,
whereas I was discussing it as associated with an indeterminate value.
" 3.19.2
1 indeterminate value
either an unspecified value or a trap representation"
We could probably agree that the value of 'c' is indeterminate.
So you would say that in C11, 'c' has an unspecified value, which, once
read, leads to undefined behaviour, and that it does not have a trap
representation, which, once read, would not lead to undefined behaviour
because of the exemption for character type lvalues.
I would say that the value of 'c' happens to have a bit pattern that is
identical to a bit pattern representing an unspecified value, but that
reading it still leads to undefined behaviour (see committee discussion
above), just as a trap representation would for non-character types of
lvalues.
So if I'd typed "indeterminate value," it mightn't've been clear that I
was emphasizing the undefined behaviour of a read. If I'd typed
"unspecified value," same problem. So I chose to type "trap
representation." But to have avoided disagreement, I suppose I ought to
have typed something longer than that.
I don't know why you might think that DR #260 and DR #338 are so
different. Both cases involve the provenance of an object's value, and
how the mapping of object representation to value isn't the whole story.
DR #260 happened to come 6 years earlier and happens to explain it
pretty nicely, in my opinion. My point way above was that since pointer
representations are opaque (unlike the only other type of scalar), then
it is convenient that "more" of "the whole story" _can_ be encoded directly.
But if you say that my use of "trap representation" in the two previous
posts above is a misuse, I will not offer an argument against that. :)
Thank you for clarifying and for [albeit indirectly] referring to the
change brought about by DR #338. (I hope.)
--
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.
Cheerily," -- Richard Harter
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2013-01-14 12:04 -0800 |
| Message-ID | <kfn7gnfcz0l.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #30074 |
Shao Miller <sha0.miller@gmail.com> writes:
> On 1/12/2013 17:52, Tim Rentsch wrote:
>> Shao Miller <sha0.miller@gmail.com> writes:
>>
>>> On 1/6/2013 23:00, Tim Rentsch wrote:
>>>> Shao Miller <sha0.miller@gmail.com> writes:
>>>>> Surely if, in
>>>>>
>>>>> void somefunc(void) {
>>>>> unsigned char c;
>>>>> /* ... */
>>>>> }
>>>>>
>>>>> 'c' is permitted to have a trap representation due to its
>>>>> "provenance,"
>>>>
>>>> It isn't. You are either mis-remembering or have misunderstood.
>>>
>>> Committee Discussion in Defect Report #260:
>>>
>>> "In addition the C Standard does not prohibit an implementation from
>>> tracking the provenance of the bit-pattern representing a value. An
>>> indeterminate value happening to have a bit pattern that is identical to
>>> a bit pattern representing a determinate value is not sufficient to
>>> allow access to the indeterminate value free from undefined behavior."
>>>
>>> That suggests to me that real implementation representatives discussed
>>> it, and some of them must have argued that there is more to object
>>> representation and value than a simple mapping. I suggest that there
>>> are other meta-considerations (such as "indeterminate value"), some of
>>> which are crucial to an implementation that wishes to have "enforceable
>>> coding rules":
>>>
>>> http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1663.pdf
>>>
>>> 'c' above is permitted to have a trap representation without even having
>>> that fact coded into its object representation. If I've misunderstood,
>>> then I apologize. If you have further knowledge of the status of DR
>>> #260, then please share! :)
>>
>> The type unsigned char does not have trap representations. There
>> are no exceptions. Types that don't have trap representations
>> never have a trap representation.
>>
>> In C11, accessing a variable like 'c' above before it has been
>> initialiized is undefined behavior. But that is because C11
>> added (relative to, eg, N1256) a specific statement regarding
>> such cases, stating explicitly that the behavior is undefined;
>> it has nothing to do with provenance or trap representations.
>> Indeed, seeing that this proviso was added in C11 makes it
>> obvious that DR 260 doesn't apply to cases like the example
>> above, because otherwise there would be no reason to add it.
>
> Now I think I understand what you are talking about, here. I think
> you are discussing a trap representation as if it is associated with a
> type, whereas I was discussing it as associated with an indeterminate
> value.
>
> " 3.19.2
> 1 indeterminate value
> either an unspecified value or a trap representation"
Whether a given object representation is a trap representation
is defined only the context of a particular type.
The term "indeterminate value" is defined in terms of (among
other things) trap representations, not the other way around.
> We could probably agree that the value of 'c' is indeterminate.
That may be true, but it has no bearing on what I said about
trap representations.
> So you would say that in C11, 'c' has an unspecified value, which,
> once read, leads to undefined behaviour, and that it does not have a
> trap representation, which, once read, would not lead to undefined
> behaviour because of the exemption for character type lvalues.
No. The reading takes place only when the behavior is, or might be,
defined. In cases like this one the undefined behavior occurs
before there is any attempt at reading (alternatively, instead
of an attempt at reading). Whether c holds a legal value or
not, or any value at all, is completely immaterial.
> I would say that the value of 'c' happens to have a bit pattern that
> is identical to a bit pattern representing an unspecified value, but
> that reading it still leads to undefined behaviour (see committee
> discussion above), just as a trap representation would for
> non-character types of lvalues. [snip elaboration]
PLease read 6.3.2.1 p2 again carefully. No reading takes place
(obviously not counting the possibility that anything could have
taken place because the behavior is undefined). What value c
has, or whether it has a value, or whether storage has even been
allocated for c, has no bearing either on what happens or how
the Standard describes what happens.
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2013-01-14 18:52 -0500 |
| Message-ID | <kd25nb$6f2$1@dont-email.me> |
| In reply to | #30133 |
On 1/14/2013 15:04, Tim Rentsch wrote:
> Shao Miller <sha0.miller@gmail.com> writes:
>
>> On 1/12/2013 17:52, Tim Rentsch wrote:
>>> Shao Miller <sha0.miller@gmail.com> writes:
>>>
>>>> On 1/6/2013 23:00, Tim Rentsch wrote:
>>>>> Shao Miller <sha0.miller@gmail.com> writes:
>>>>>> Surely if, in
>>>>>>
>>>>>> void somefunc(void) {
>>>>>> unsigned char c;
>>>>>> /* ... */
>>>>>> }
>>>>>>
>>>>>> 'c' is permitted to have a trap representation due to its
>>>>>> "provenance,"
>>>>>
>>>>> It isn't. You are either mis-remembering or have misunderstood.
>>>>
>>>> Committee Discussion in Defect Report #260:
>>>>
>>>> "In addition the C Standard does not prohibit an implementation from
>>>> tracking the provenance of the bit-pattern representing a value. An
>>>> indeterminate value happening to have a bit pattern that is identical to
>>>> a bit pattern representing a determinate value is not sufficient to
>>>> allow access to the indeterminate value free from undefined behavior."
>>>>
>>>> That suggests to me that real implementation representatives discussed
>>>> it, and some of them must have argued that there is more to object
>>>> representation and value than a simple mapping. I suggest that there
>>>> are other meta-considerations (such as "indeterminate value"), some of
>>>> which are crucial to an implementation that wishes to have "enforceable
>>>> coding rules":
>>>>
>>>> http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1663.pdf
>>>>
>>>> 'c' above is permitted to have a trap representation without even having
>>>> that fact coded into its object representation. If I've misunderstood,
>>>> then I apologize. If you have further knowledge of the status of DR
>>>> #260, then please share! :)
>>>
>>> The type unsigned char does not have trap representations. There
>>> are no exceptions. Types that don't have trap representations
>>> never have a trap representation.
>>>
>>> In C11, accessing a variable like 'c' above before it has been
>>> initialiized is undefined behavior. But that is because C11
>>> added (relative to, eg, N1256) a specific statement regarding
>>> such cases, stating explicitly that the behavior is undefined;
>>> it has nothing to do with provenance or trap representations.
>>> Indeed, seeing that this proviso was added in C11 makes it
>>> obvious that DR 260 doesn't apply to cases like the example
>>> above, because otherwise there would be no reason to add it.
>>
>> Now I think I understand what you are talking about, here. I think
>> you are discussing a trap representation as if it is associated with a
>> type, whereas I was discussing it as associated with an indeterminate
>> value.
>>
>> " 3.19.2
>> 1 indeterminate value
>> either an unspecified value or a trap representation"
>
> Whether a given object representation is a trap representation
> is defined only the context of a particular type.
>
Yes I think I grok your model (but could be mistaken)... If I
understand you correctly, type T has _exactly_ 2 to the power of (sizeof
(T) * CHAR_BIT) possible object representations. At some time S during
execution, those object representations can be partitioned thusly: Valid
values, trap representations. Furthermore, different object
representations can represent the same value.
Have I described your model correctly? Does S make any difference in
your model? At time S, is the partitioning the same for all objects
with type T, or can it be different for different objects?
> The term "indeterminate value" is defined in terms of (among
> other things) trap representations, not the other way around.
>
Agreed.
>> We could probably agree that the value of 'c' is indeterminate.
>
> That may be true, but it has no bearing on what I said about
> trap representations.
>
I assume that you are referring to the equivalent of "An object with
type 'unsigned char' cannot possess an object representation that is a
trap representation for that type, as there are no trap representations
for 'unsigned char'"
>> So you would say that in C11, 'c' has an unspecified value, which,
>> once read, leads to undefined behaviour, and that it does not have a
>> trap representation, which, once read, would not lead to undefined
>> behaviour because of the exemption for character type lvalues.
>
> No. The reading takes place only when the behavior is, or might be,
> defined. In cases like this one the undefined behavior occurs
> before there is any attempt at reading (alternatively, instead
> of an attempt at reading). Whether c holds a legal value or
> not, or any value at all, is completely immaterial.
>
>> I would say that the value of 'c' happens to have a bit pattern that
>> is identical to a bit pattern representing an unspecified value, but
>> that reading it still leads to undefined behaviour (see committee
>> discussion above), just as a trap representation would for
>> non-character types of lvalues. [snip elaboration]
>
> PLease read 6.3.2.1 p2 again carefully. No reading takes place
> (obviously not counting the possibility that anything could have
> taken place because the behavior is undefined). What value c
> has, or whether it has a value, or whether storage has even been
> allocated for c, has no bearing either on what happens or how
> the Standard describes what happens.
>
Ok, I've re-read it. I don't understand what you've just said in the
last sentence and in the sentence further above it "Whether c...". I'd
better return to "We could probably agree that the value of 'c' is
indeterminate". Is this true?
I'll assume that you're uninterested in my explanation of why I used the
term "trap representation", since you know it to be one thing and I
meant something else.
I'll assume that you're uninterested in discussing potential
similarities between DR #260 and DR #338, since you've already stated
that you do not believe DR #260 is relevant, and explained why.
Once I've understood what you mean by "trap representation," perhaps I
can adjust my "Surely if..." accordingly.
Thank you.
--
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.
Cheerily," -- Richard Harter
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2013-01-16 00:01 -0800 |
| Message-ID | <kfnd2x5blq0.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #30145 |
Shao Miller <sha0.miller@gmail.com> writes:
> On 1/14/2013 15:04, Tim Rentsch wrote:
>> Shao Miller <sha0.miller@gmail.com> writes:
>>
>>> On 1/12/2013 17:52, Tim Rentsch wrote:
>>>> Shao Miller <sha0.miller@gmail.com> writes:
>>>>
>>>>> On 1/6/2013 23:00, Tim Rentsch wrote:
>>>>>> Shao Miller <sha0.miller@gmail.com> writes:
>>>>>>> Surely if, in
>>>>>>>
>>>>>>> void somefunc(void) {
>>>>>>> unsigned char c;
>>>>>>> /* ... */
>>>>>>> }
>>>>>>>
>> > > [snip]
>>>
>>> I would say that the value of 'c' happens to have a bit pattern that
>>> is identical to a bit pattern representing an unspecified value, but
>>> that reading it still leads to undefined behaviour (see committee
>>> discussion above), just as a trap representation would for
>>> non-character types of lvalues. [snip elaboration]
>>
>> PLease read 6.3.2.1 p2 again carefully. No reading takes place
>> (obviously not counting the possibility that anything could have
>> taken place because the behavior is undefined). What value c
>> has, or whether it has a value, or whether storage has even been
>> allocated for c, has no bearing either on what happens or how
>> the Standard describes what happens.
>
> Ok, I've re-read it. I don't understand ... [snip]
Think, man, think! This isn't that hard of a problem.
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2013-01-16 05:43 -0500 |
| Message-ID | <kd6099$7l7$1@dont-email.me> |
| In reply to | #30182 |
On 1/16/2013 03:01, Tim Rentsch wrote:
> Shao Miller <sha0.miller@gmail.com> writes:
>
>> On 1/14/2013 15:04, Tim Rentsch wrote:
>>> Shao Miller <sha0.miller@gmail.com> writes:
>>>
>>>> On 1/12/2013 17:52, Tim Rentsch wrote:
>>>>> Shao Miller <sha0.miller@gmail.com> writes:
>>>>>
>>>>>> On 1/6/2013 23:00, Tim Rentsch wrote:
>>>>>>> Shao Miller <sha0.miller@gmail.com> writes:
>>>>>>>> Surely if, in
>>>>>>>>
>>>>>>>> void somefunc(void) {
>>>>>>>> unsigned char c;
>>>>>>>> /* ... */
>>>>>>>> }
>>>>>>>>
>>>>> [snip]
>>>>
>>>> I would say that the value of 'c' happens to have a bit pattern that
>>>> is identical to a bit pattern representing an unspecified value, but
>>>> that reading it still leads to undefined behaviour (see committee
>>>> discussion above), just as a trap representation would for
>>>> non-character types of lvalues. [snip elaboration]
>>>
>>> PLease read 6.3.2.1 p2 again carefully. No reading takes place
>>> (obviously not counting the possibility that anything could have
>>> taken place because the behavior is undefined). What value c
>>> has, or whether it has a value, or whether storage has even been
>>> allocated for c, has no bearing either on what happens or how
>>> the Standard describes what happens.
>>
>> Ok, I've re-read it. I don't understand ... [snip]
>
> Think, man, think! This isn't that hard of a problem.
>
Too long; didn't read. :)
But seriously, I'd tried to break this part of the discussion into tiny
little pieces. My previous post had 4 questions. Three of them could
be answered with "yes" or "no" and the other also had two possible
answers. Is that so much to ask?
Instead, you type a one-liner that answers none of the questions,
doesn't demonstrate that agreement or understanding are even possible,
presents me to be stupid, causes me to respond with a disproportionate
amount of text in an attempt to pull some teeth, while at other times
you complain about the amount I type. That hardly seems fair.
I'll tell you what I think: I think you've misunderstood what I don't
understand about what you said. I didn't say that I don't understand
your point about the UB coming before an act of reading.
I don't know if you are trying to hint that this undefined behaviour is
at translation-time, or something. It can't always be.
unsigned char scary(int x) {
unsigned char c;
if (x == 42)
c = '\0';
return c;
}
What I didn't understand is:
- Why you'd type "Whether c holds a legal value or not, or any value
at all, is completely immaterial". 6.3.2.1p2 seems to indicate that
it's _not_ immaterial. If it's initialized or assigned-to, it
_certainly_ holds a valid value (short of any prior UB).
- Why you'd type "What value c has, or whether it has a value, or
whether storage has even been allocated for c, has no bearing either on
what happens or how the Standard describes what happens". 6.3.2.1p2
seems to indicate that it _does_ have a bearing on what happens. If
it's initialized or assigned-to, it _certainly_ holds a valid value and
has storage (short of any prior UB).
That is to say, if we can prove[2] it has a valid value, then we can
deduce that it was initialized or assigned-to, because that proof[2]
must involve such operations. Please remember that I was originally
talking about the possibility that 'c' could have a trap
representation[1]. If that[1] is false, then the proof[2] of this other
business _needn't_ involve such operations; there're only unspecified
values allowed. But you can't establish that trap representation[1] is
false by explaining how some other form of undefined behaviour is true,
so I didn't understand the relevance of your two statements.
It looked like you were making general statements, but perhaps you were
addressing _only_ the code example at the top, which _could_ be detected
at translation-time?
What about the rest of my previous post? Instead of giving a response
to each of the bits that might lead to some common ground, you've given
a cryptic response to one bit. It's like taking a sound-bite of a
politician saying "Uhhh" and promoting their stupidity in a campaign
against them, because stupid people frequently say "uhhh". If you'd
snipped after four more words, it'd be slightly different. But perhaps
this is where you snip in your mind, as well. "He doesn't understand
something, so he needs to think more!" :)
--
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.
Cheerily," -- Richard Harter
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2013-01-16 09:01 -0800 |
| Message-ID | <jumdf8d5fumvt4hhsuaakvma22pm3p7lf6@4ax.com> |
| In reply to | #30192 |
On Wed, 16 Jan 2013 05:43:52 -0500, Shao Miller
<sha0.miller@gmail.com> wrote:
> unsigned char scary(int x) {
> unsigned char c;
>
> if (x == 42)
> c = '\0';
> return c;
> }
>
Eh? What is the value of c when x is not 42?
What is contained in object c prior to the 'if' statement?
What code is executed when x is not 42?
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2013-01-16 18:32 -0500 |
| Message-ID | <kd7das$p8$1@dont-email.me> |
| In reply to | #30201 |
On 1/16/2013 12:01, Geoff wrote:
> On Wed, 16 Jan 2013 05:43:52 -0500, Shao Miller
> <sha0.miller@gmail.com> wrote:
>
>> unsigned char scary(int x) {
>> unsigned char c;
>>
>> if (x == 42)
>> c = '\0';
>> return c;
>> }
>>
>
> Eh? What is the value of c when x is not 42?
> What is contained in object c prior to the 'if' statement?
> What code is executed when x is not 42?
>
In order, excluding the first question: "Indeterminate", "an
indeterminate value", "'return c;'".
But don't be fooled, this indeterminate value is not just any ordinary
indeterminate value, it is one that we can never know, since using the
lvalue in a context in which it'd normally result in a read causes
undefined behaviour. Depending on who you ask, it does or doesn't look
like a trap representation, but quacks just like one, but a little
earlier than a TR would, in C11.
The C11 additional sentence to 6.3.2.1p2 was prompted by Defect Report
#338. The submitter suggested that "indeterminate value" be amended:
"either an unspecified value or a trap representation; or in the case
of an object of automatic storage duration whose address is never taken,
a value that behaves as if it were a trap representation, even for types
that have no trap representations in memory (including type unsigned char)"
In SC22WG14.11380, Mr. Douglas Gwyn suggests, "Trap rep. was an
unfortunate choice of name, having no necessary connection with
trapping; it was only meant to describe any bit configuration that would
not be a valid representation for the type."
In N1300.pdf, Mr. Clark Nelson suggested that besides a "variable"
having a valid value or a trap representation, another possible state
was "uninitialized", and that either of the other two states could still
apply.
--
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.
Cheerily," -- Richard Harter
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2013-01-16 17:32 -0800 |
| Message-ID | <mjjef8p51si1foqldld20crejf9u8h7qc6@4ax.com> |
| In reply to | #30218 |
On Wed, 16 Jan 2013 18:32:43 -0500, Shao Miller <sha0.miller@gmail.com> wrote:
>On 1/16/2013 12:01, Geoff wrote:
>> On Wed, 16 Jan 2013 05:43:52 -0500, Shao Miller
>> <sha0.miller@gmail.com> wrote:
>>
>>> unsigned char scary(int x) {
>>> unsigned char c;
>>>
>>> if (x == 42)
>>> c = '\0';
>>> return c;
>>> }
>>>
>>
>> Eh? What is the value of c when x is not 42?
>> What is contained in object c prior to the 'if' statement?
>> What code is executed when x is not 42?
>>
>
>In order, excluding the first question: "Indeterminate", "an
>indeterminate value", "'return c;'".
>
>But don't be fooled, this indeterminate value is not just any ordinary
>indeterminate value, it is one that we can never know, since using the
>lvalue in a context in which it'd normally result in a read causes
>undefined behaviour. Depending on who you ask, it does or doesn't look
>like a trap representation, but quacks just like one, but a little
>earlier than a TR would, in C11.
>
>The C11 additional sentence to 6.3.2.1p2 was prompted by Defect Report
>#338. The submitter suggested that "indeterminate value" be amended:
>
> "either an unspecified value or a trap representation; or in the case
>of an object of automatic storage duration whose address is never taken,
>a value that behaves as if it were a trap representation, even for types
>that have no trap representations in memory (including type unsigned char)"
>
>In SC22WG14.11380, Mr. Douglas Gwyn suggests, "Trap rep. was an
>unfortunate choice of name, having no necessary connection with
>trapping; it was only meant to describe any bit configuration that would
>not be a valid representation for the type."
>
>In N1300.pdf, Mr. Clark Nelson suggested that besides a "variable"
>having a valid value or a trap representation, another possible state
>was "uninitialized", and that either of the other two states could still
>apply.
>
I think what they might have been driving at with "trap representation" was the
possibility that the environment (e.g., a debugger or a debugging runtime) could
initialize the contents to a determinate value. This would be analogous to
Microsoft's debugger putting 0xCC, 0xDD, 0xCF values into various portions of
the process memory space, allowing coders to "trap" uninitialized variables. I
think the proper word would be "detect".
I think the language of the specification would have to allow this facility but
not define it.
Microsoft documents their compiler trap values:
Value Name Description
------ -------- -------------------------
0xCD Clean Memory Allocated memory via malloc or new but never
written by the application.
0xDD Dead Memory Memory that has been released with delete or
free.
Used to detect writing through dangling
pointers.
0xED or Aligned Fence 'No man's land' for aligned allocations.
0xBD Using a different value here than 0xFD
allows the runtime to detect not only
writing outside the allocation,
but to also detect mixing alignment-specific
allocation/deallocation routines with the
regular ones.
0xFD Fence Memory Also known as "no mans land." This is used to
wrap the allocated memory (surrounding it
with a fence) and is used to detect indexing
arrays out of bounds or other accesses
(especially writes) past
the end (or start) of an allocated block.
0xFD or Buffer slack Used to fill slack space in some memory buffers
0xFE (unused parts of `std::string` or the user buffer
passed to `fread()`). 0xFD is used in VS 2005 (maybe
some prior versions, too), 0xFE is used in VS 2008
and later.
0xCC When the code is compiled with the /GZ option,
uninitialized variables are automatically assigned
to this value (at byte level).
// the following magic values are done by the OS, not the C runtime:
0xAB (Allocated Block?) Memory allocated by LocalAlloc().
0xBAADF00D Bad Food Memory allocated by LocalAlloc() with LMEM_FIXED,but
not yet written to.
0xFEEEFEEE OS fill heap memory, which was marked for usage,
but wasn't allocated by HeapAlloc() or LocalAlloc().
Or that memory just has been freed by HeapFree().
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2013-01-16 20:57 -0500 |
| Message-ID | <kd7lpi$epe$1@dont-email.me> |
| In reply to | #30227 |
On 1/16/2013 20:32, Geoff wrote:
> On Wed, 16 Jan 2013 18:32:43 -0500, Shao Miller <sha0.miller@gmail.com> wrote:
>
>> On 1/16/2013 12:01, Geoff wrote:
>>> On Wed, 16 Jan 2013 05:43:52 -0500, Shao Miller
>>> <sha0.miller@gmail.com> wrote:
>>>
>>>> unsigned char scary(int x) {
>>>> unsigned char c;
>>>>
>>>> if (x == 42)
>>>> c = '\0';
>>>> return c;
>>>> }
>>>>
>>>
>>> Eh? What is the value of c when x is not 42?
>>> What is contained in object c prior to the 'if' statement?
>>> What code is executed when x is not 42?
>>>
>>
>> In order, excluding the first question: "Indeterminate", "an
>> indeterminate value", "'return c;'".
>>
>> But don't be fooled, this indeterminate value is not just any ordinary
>> indeterminate value, it is one that we can never know, since using the
>> lvalue in a context in which it'd normally result in a read causes
>> undefined behaviour. Depending on who you ask, it does or doesn't look
>> like a trap representation, but quacks just like one, but a little
>> earlier than a TR would, in C11.
>>
>> The C11 additional sentence to 6.3.2.1p2 was prompted by Defect Report
>> #338. The submitter suggested that "indeterminate value" be amended:
>>
>> "either an unspecified value or a trap representation; or in the case
>> of an object of automatic storage duration whose address is never taken,
>> a value that behaves as if it were a trap representation, even for types
>> that have no trap representations in memory (including type unsigned char)"
>>
>> In SC22WG14.11380, Mr. Douglas Gwyn suggests, "Trap rep. was an
>> unfortunate choice of name, having no necessary connection with
>> trapping; it was only meant to describe any bit configuration that would
>> not be a valid representation for the type."
>>
>> In N1300.pdf, Mr. Clark Nelson suggested that besides a "variable"
>> having a valid value or a trap representation, another possible state
>> was "uninitialized", and that either of the other two states could still
>> apply.
>>
>
> I think what they might have been driving at with "trap representation" was the
> possibility that the environment (e.g., a debugger or a debugging runtime) could
> initialize the contents to a determinate value. This would be analogous to
> Microsoft's debugger putting 0xCC, 0xDD, 0xCF values into various portions of
> the process memory space, allowing coders to "trap" uninitialized variables. I
> think the proper word would be "detect".
>
> I think the language of the specification would have to allow this facility but
> not define it.
>
While that is certainly consistent with my experiences (having worked
with Microsoft environments for over a decade) where there isn't always
the luxury of having padding bits, and so seems an intuitive notion of
"trap representation" in _practice_, it doesn't seem 100% consistent
with Mr. Douglas Gwyn's note nor with perhaps the strictest reading of
the Standard, as Mr. T. Rentsch points out upthread. Oh well, we can
call it something else in discussion, such as "trappable-unspecified
value", so the term isn't confused with a Standard-defined term.
> Microsoft documents their compiler trap values:
> Value Name Description
> ------ -------- -------------------------
> 0xCD Clean Memory Allocated memory via malloc or new but never
> written by the application.
>
> 0xDD Dead Memory Memory that has been released with delete or
> free.
> Used to detect writing through dangling
> pointers.
>
> 0xED or Aligned Fence 'No man's land' for aligned allocations.
> 0xBD Using a different value here than 0xFD
> allows the runtime to detect not only
> writing outside the allocation,
> but to also detect mixing alignment-specific
> allocation/deallocation routines with the
> regular ones.
>
> 0xFD Fence Memory Also known as "no mans land." This is used to
> wrap the allocated memory (surrounding it
> with a fence) and is used to detect indexing
> arrays out of bounds or other accesses
> (especially writes) past
> the end (or start) of an allocated block.
>
> 0xFD or Buffer slack Used to fill slack space in some memory buffers
> 0xFE (unused parts of `std::string` or the user buffer
> passed to `fread()`). 0xFD is used in VS 2005 (maybe
> some prior versions, too), 0xFE is used in VS 2008
> and later.
>
> 0xCC When the code is compiled with the /GZ option,
> uninitialized variables are automatically assigned
> to this value (at byte level).
>
>
> // the following magic values are done by the OS, not the C runtime:
>
> 0xAB (Allocated Block?) Memory allocated by LocalAlloc().
>
> 0xBAADF00D Bad Food Memory allocated by LocalAlloc() with LMEM_FIXED,but
> not yet written to.
>
> 0xFEEEFEEE OS fill heap memory, which was marked for usage,
> but wasn't allocated by HeapAlloc() or LocalAlloc().
> Or that memory just has been freed by HeapFree().
>
Wonderful, wonderful summary! I thought null pointers having 0x0C as
the least-significant byte was "a thing," too, but now I can't remember
having seen that documented anywhere.
--
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.
Cheerily," -- Richard Harter
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-01-17 07:55 -0800 |
| Message-ID | <ln4nifby8p.fsf@nuthaus.mib.org> |
| In reply to | #30228 |
Shao Miller <sha0.miller@gmail.com> writes:
> On 1/16/2013 20:32, Geoff wrote:
[...]
>> Microsoft documents their compiler trap values:
>> Value Name Description
>> ------ -------- -------------------------
>> 0xCD Clean Memory Allocated memory via malloc or new but never
>> written by the application.
>>
[snip]
>> 0xFEEEFEEE OS fill heap memory, which was marked for usage,
>> but wasn't allocated by HeapAlloc() or LocalAlloc().
>> Or that memory just has been freed by HeapFree().
>
> Wonderful, wonderful summary! I thought null pointers having 0x0C as
> the least-significant byte was "a thing," too, but now I can't remember
> having seen that documented anywhere.
I'm fairly sure Microsoft uses all-bits-zero for null pointers. Most
implementations do the same thing, though of course the standard doesn't
require it.
--
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 | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2013-01-17 16:47 -0500 |
| Message-ID | <kd9ria$pqs$1@dont-email.me> |
| In reply to | #30259 |
On 1/17/2013 10:55, Keith Thompson wrote: > Shao Miller <sha0.miller@gmail.com> writes: >> On 1/16/2013 20:32, Geoff wrote: > [...] >>> Microsoft documents their compiler trap values: >>> Value Name Description >>> ------ -------- ------------------------- >>> 0xCD Clean Memory Allocated memory via malloc or new but never >>> written by the application. >>> > [snip] >>> 0xFEEEFEEE OS fill heap memory, which was marked for usage, >>> but wasn't allocated by HeapAlloc() or LocalAlloc(). >>> Or that memory just has been freed by HeapFree(). >> >> Wonderful, wonderful summary! I thought null pointers having 0x0C as >> the least-significant byte was "a thing," too, but now I can't remember >> having seen that documented anywhere. > > I'm fairly sure Microsoft uses all-bits-zero for null pointers. Most > implementations do the same thing, though of course the standard doesn't > require it. > I think all-bits-zero is one null pointer value representation, but I was talking about "trap representations" in practice (as opposed to a discussion of those that depend on padding bits). In Windows NT kernel-land, more often than not I see that when a null pointer is trapped, it's actually _not_ all-bits-zero; differing in the LSB. The debugger still calls it a null pointer. -- - Shao Miller -- "Thank you for the kind words; those are the kind of words I like to hear. Cheerily," -- Richard Harter
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-01-18 08:41 -0800 |
| Message-ID | <lnip6ua1f4.fsf@nuthaus.mib.org> |
| In reply to | #30274 |
Shao Miller <sha0.miller@gmail.com> writes:
> On 1/17/2013 10:55, Keith Thompson wrote:
>> Shao Miller <sha0.miller@gmail.com> writes:
>>> On 1/16/2013 20:32, Geoff wrote:
>> [...]
>>>> Microsoft documents their compiler trap values:
>>>> Value Name Description
>>>> ------ -------- -------------------------
>>>> 0xCD Clean Memory Allocated memory via malloc or new but never
>>>> written by the application.
>>>>
>> [snip]
>>>> 0xFEEEFEEE OS fill heap memory, which was marked for usage,
>>>> but wasn't allocated by HeapAlloc() or LocalAlloc().
>>>> Or that memory just has been freed by HeapFree().
>>>
>>> Wonderful, wonderful summary! I thought null pointers having 0x0C as
>>> the least-significant byte was "a thing," too, but now I can't remember
>>> having seen that documented anywhere.
>>
>> I'm fairly sure Microsoft uses all-bits-zero for null pointers. Most
>> implementations do the same thing, though of course the standard doesn't
>> require it.
>
> I think all-bits-zero is one null pointer value representation, but I
> was talking about "trap representations" in practice (as opposed to a
> discussion of those that depend on padding bits). In Windows NT
> kernel-land, more often than not I see that when a null pointer is
> trapped, it's actually _not_ all-bits-zero; differing in the LSB. The
> debugger still calls it a null pointer.
A null pointer is not a trap representation; it's a perfectly valid
pointer value (that can't legally be dereferenced).
What exactly do you mean when you say "The debugger still calls it a
null pointer"? Does the debugger actually use the phrase "null pointer"
to refer to a pointer value that compares unequal to NULL?
--
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 | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2013-01-18 15:53 -0500 |
| Message-ID | <kdccnu$b7s$1@dont-email.me> |
| In reply to | #30306 |
On 1/18/2013 11:41, Keith Thompson wrote: > Shao Miller <sha0.miller@gmail.com> writes: >> On 1/17/2013 10:55, Keith Thompson wrote: >>> Shao Miller <sha0.miller@gmail.com> writes: >>>> On 1/16/2013 20:32, Geoff wrote: >>> [...] >>>>> Microsoft documents their compiler trap values: >>>>> Value Name Description >>>>> ------ -------- ------------------------- >>>>> 0xCD Clean Memory Allocated memory via malloc or new but never >>>>> written by the application. >>>>> >>> [snip] >>>>> 0xFEEEFEEE OS fill heap memory, which was marked for usage, >>>>> but wasn't allocated by HeapAlloc() or LocalAlloc(). >>>>> Or that memory just has been freed by HeapFree(). >>>> >>>> Wonderful, wonderful summary! I thought null pointers having 0x0C as >>>> the least-significant byte was "a thing," too, but now I can't remember >>>> having seen that documented anywhere. >>> >>> I'm fairly sure Microsoft uses all-bits-zero for null pointers. Most >>> implementations do the same thing, though of course the standard doesn't >>> require it. >> >> I think all-bits-zero is one null pointer value representation, but I >> was talking about "trap representations" in practice (as opposed to a >> discussion of those that depend on padding bits). In Windows NT >> kernel-land, more often than not I see that when a null pointer is >> trapped, it's actually _not_ all-bits-zero; differing in the LSB. The >> debugger still calls it a null pointer. > > A null pointer is not a trap representation; it's a perfectly valid > pointer value (that can't legally be dereferenced). > Agreed. And that's kind of what I was getting at... That this representation is: 1. A valid null pointer representation (behaves as a null pointer in C code; no undefined behaviour from using this pointer value unless dereferencing) 2. Very consistently _not_ all-bits-zero, suggesting a practical use for a debugger to trap (as opposed to a same-sized integer/object with all-zeroes) > What exactly do you mean when you say "The debugger still calls it a > null pointer"? Does the debugger actually use the phrase "null pointer" > to refer to a pointer value that compares unequal to NULL? > It absolutely does. (I see it more often than I'd like, some days. ;) ) I suspect that it's an instance of trap representations in practice, as opposed to "trap representations" in C theory. -- - Shao Miller -- "Thank you for the kind words; those are the kind of words I like to hear. Cheerily," -- Richard Harter
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-01-18 17:38 -0800 |
| Message-ID | <ln622u9clc.fsf@nuthaus.mib.org> |
| In reply to | #30321 |
Shao Miller <sha0.miller@gmail.com> writes:
> On 1/18/2013 11:41, Keith Thompson wrote:
>> Shao Miller <sha0.miller@gmail.com> writes:
[...]
>>> I think all-bits-zero is one null pointer value representation, but I
>>> was talking about "trap representations" in practice (as opposed to a
>>> discussion of those that depend on padding bits). In Windows NT
>>> kernel-land, more often than not I see that when a null pointer is
>>> trapped, it's actually _not_ all-bits-zero; differing in the LSB. The
>>> debugger still calls it a null pointer.
>>
>> A null pointer is not a trap representation; it's a perfectly valid
>> pointer value (that can't legally be dereferenced).
>>
>
> Agreed. And that's kind of what I was getting at... That this
> representation is:
>
> 1. A valid null pointer representation (behaves as a null pointer in C
> code; no undefined behaviour from using this pointer value unless
> dereferencing)
>
> 2. Very consistently _not_ all-bits-zero, suggesting a practical use for
> a debugger to trap (as opposed to a same-sized integer/object with
> all-zeroes)
When you say it "behaves as a null pointer in C code", what exactly do
you mean by that?
Does it compare equal to NULL? If not, then it *doesn't* behave as a
null pointer in C code.
>> What exactly do you mean when you say "The debugger still calls it a
>> null pointer"? Does the debugger actually use the phrase "null pointer"
>> to refer to a pointer value that compares unequal to NULL?
>
> It absolutely does. (I see it more often than I'd like, some days. ;) )
> I suspect that it's an instance of trap representations in practice,
> as opposed to "trap representations" in C theory.
A lot of technical terms have specific meanings in C that may not apply
in other contexts. If a debugger refers to something other than a C
null pointer as a "null pointer", then (a) it's a pity that a tool that
deals with C source code uses a term in a manner that's inconsistent
with the C meaning of the term, but (b) it doesn't have much direct
bearing on C (i.e., on anything relevant to this newsgroup).
Can you point to some documentation that discusses this use of the term
"null pointer"?
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-01-19 02:31 +0000 |
| Message-ID | <kdd0ii$agi$1@speranza.aioe.org> |
| In reply to | #30334 |
Keith Thompson <kst-u@mib.org> wrote: > Shao Miller <sha0.miller@gmail.com> writes: (snip) >> 2. Very consistently _not_ all-bits-zero, suggesting a practical use for >> a debugger to trap (as opposed to a same-sized integer/object with >> all-zeroes) > When you say it "behaves as a null pointer in C code", what exactly do > you mean by that? > Does it compare equal to NULL? If not, then it *doesn't* behave as a > null pointer in C code. I can imagine a system that masks off some bits before comparing it to NULL. Not that I know any that actually do it. (snip) > A lot of technical terms have specific meanings in C that may not apply > in other contexts. If a debugger refers to something other than a C > null pointer as a "null pointer", then (a) it's a pity that a tool that > deals with C source code uses a term in a manner that's inconsistent > with the C meaning of the term, but (b) it doesn't have much direct > bearing on C (i.e., on anything relevant to this newsgroup). > Can you point to some documentation that discusses this use of the term > "null pointer"? -- glen
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2013-01-18 23:15 -0500 |
| Message-ID | <kdd6lm$ik6$1@dont-email.me> |
| In reply to | #30336 |
On 1/18/2013 21:31, glen herrmannsfeldt wrote:
> Keith Thompson <kst-u@mib.org> wrote:
>> Shao Miller <sha0.miller@gmail.com> writes:
>
> (snip)
>>> 2. Very consistently _not_ all-bits-zero, suggesting a practical use for
>>> a debugger to trap (as opposed to a same-sized integer/object with
>>> all-zeroes)
>
>> When you say it "behaves as a null pointer in C code", what exactly do
>> you mean by that?
>
>> Does it compare equal to NULL? If not, then it *doesn't* behave as a
>> null pointer in C code.
>
> I can imagine a system that masks off some bits before comparing
> it to NULL. Not that I know any that actually do it.
>
Yes well that's along the lines that it might be. For example, if a
'free'd pointer becomes 0x0000000C, in C terminology, it'd be an
"indeterminate value." But, using C terminology again, it'd be an
"unspecified value" rather than a "trap representation", as the value
can be read and passed around. In C terminology, it would "point to no
object", just as a "null pointer" does. Upon dereferencing though,
Windows could tell from the representation just what the problem was:
Use of a 'free'd pointer. And yes, the higher bits might indicate that
it was a pointer that points to no object ("null class", perhaps we
could call it).
--
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.
Cheerily," -- Richard Harter
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2013-01-19 20:03 -0800 |
| Message-ID | <lna9s48prb.fsf@nuthaus.mib.org> |
| In reply to | #30338 |
Shao Miller <sha0.miller@gmail.com> writes:
> On 1/18/2013 21:31, glen herrmannsfeldt wrote:
>> Keith Thompson <kst-u@mib.org> wrote:
>>> Shao Miller <sha0.miller@gmail.com> writes:
>>
>> (snip)
>>>> 2. Very consistently _not_ all-bits-zero, suggesting a practical use for
>>>> a debugger to trap (as opposed to a same-sized integer/object with
>>>> all-zeroes)
>>
>>> When you say it "behaves as a null pointer in C code", what exactly do
>>> you mean by that?
>>
>>> Does it compare equal to NULL? If not, then it *doesn't* behave as a
>>> null pointer in C code.
>>
>> I can imagine a system that masks off some bits before comparing
>> it to NULL. Not that I know any that actually do it.
>
> Yes well that's along the lines that it might be. For example, if a
> 'free'd pointer becomes 0x0000000C, in C terminology, it'd be an
> "indeterminate value."
[...]
How does a free'd pointer *become* anything?
For example:
int *p = malloc(sizeof *p);
// Assume malloc() succeeded
// Assume the representation of p, when viewed as
// bytes, is 0x12, 0x34, 0x56, 0x78
free(p);
// Any attempt to refer to the value of p has undefined behavior.
// But if you examine its representation, say by type-punning it
// as an array of unsigned char, it will still look like
// 0x12, 0x34, 0x56, 0x78
The argument to free() is passed *by value*, so free() can't modify the
contents of the pointer object. The argument needn't even be an lvalue;
free(p + 1 - 1) is perfectly valid.
An implementation *could* do some sort of compiler magic, changing the
representation of a pointer object passed to free(), but (a) I don't
think it would be worth the effort, and (b) it's not clear that it would
even be conforming (the bytes making up the representation of the
pointer are objects in their own right, whose values don't change unless
you write to them). In any case, I'm not aware that Microsoft's
implementation does this -- nor am I aware that it implements "==" on
pointers so that anything other that all-bits-zero would compare equal
to NULL.
There are a lot of strange things an implementation *could* do, but the
topic at hand is what a particular implementation actually does.
Storing some specific byte sequence in uninitialized objects is a great
idea, but it doesn't have much to do with null pointers as C defines the
term.
--
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 | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2013-01-20 02:19 -0500 |
| Message-ID | <kdg5qf$fuk$1@dont-email.me> |
| In reply to | #30373 |
On 1/19/2013 23:03, Keith Thompson wrote: > Shao Miller <sha0.miller@gmail.com> writes: >> On 1/18/2013 21:31, glen herrmannsfeldt wrote: >>> Keith Thompson <kst-u@mib.org> wrote: >>>> Shao Miller <sha0.miller@gmail.com> writes: >>> >>> (snip) >>>>> 2. Very consistently _not_ all-bits-zero, suggesting a practical use for >>>>> a debugger to trap (as opposed to a same-sized integer/object with >>>>> all-zeroes) >>> >>>> When you say it "behaves as a null pointer in C code", what exactly do >>>> you mean by that? >>> >>>> Does it compare equal to NULL? If not, then it *doesn't* behave as a >>>> null pointer in C code. >>> >>> I can imagine a system that masks off some bits before comparing >>> it to NULL. Not that I know any that actually do it. >> >> Yes well that's along the lines that it might be. For example, if a >> 'free'd pointer becomes 0x0000000C, in C terminology, it'd be an >> "indeterminate value." > [...] > > How does a free'd pointer *become* anything? > The value of a pointer becomes indeterminate at the end of the pointed-to object's lifetime. Defect Report #260 discusses this. Windows "Checked" builds are more easily debugged than their "Free" counterparts. I don't think a freed pointer's representation changing is beyond the realm of either possible or useful. But "might," above, means that this was just a guess, which now seems likely to be wrong, thanks to Mr. Philip Lantz' more obvious explanation. However, the masking of bits that Mr. Glen Herrmannsfeldt mentioned still seems about right. Here is another guess: The "null class pointer" that WinDbg talks about is some reasonably-sized window around the unsigned value 0. Given a null pointer of all-zeroes, the 'CONTAINING_RECORD' macro could yield, let's say, 0xFFFFFFF0. Mr. Lantz' example shows the other direction. > [...] > > There are a lot of strange things an implementation *could* do, but the > topic at hand is what a particular implementation actually does. > Storing some specific byte sequence in uninitialized objects is a great > idea, but it doesn't have much to do with null pointers as C defines the > term. > Which of these most closely resembles the pointer value 0x0000000C in this Windows scenario?: 1. A trap representation for some pointer type, invoking UB when read 2. A valid value for some pointer type; pointing to an object 3. A null pointer; pointing to no object, invoking UB when dereferenced If it doesn't compare equal to 'NULL', then it doesn't appear to match any of these. But if we can fuzz our way from Standard theory to real-world practice, we might note some similarities to #3. Perhaps interestingly, Mr. Lantz' explanation actually means the representation gives hints about which member of a structure was involved in a bug. In Windows, many "object types" (not to be confused with the C notions) are C structures beginning with a common initial sequence. A "bad" pointer might reveal which member of this common initial sequence was involved in a bug. :) This isn't the "pointer was freed" guess of above, but still useful! (By the way, I've asked in another forum about possible documentation for NULL_CLASS_PTR_DEREFERENCE, although I don't know if you or anyone else cares.) -- - Shao Miller -- "Thank you for the kind words; those are the kind of words I like to hear. Cheerily," -- Richard Harter
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web