将地址转换为（id）是否有副作用???(Does casting an address to (id) have side

将地址转换为（id）是否有副作用???(Does casting an address to (id) have side-effects??? Is Address 0xbfffe8d0 special? (fixed: issue was with _NSCallStackArray))

以下代码行导致我的程序以一种非常奇怪的方式中断...

id foo = (id)0xbfffe8d0;

然而，这没有问题：

int foo = (int)(id)0xbfffe8d0;

即便这样也没问题：

int magicAddr = 0xbfffe8d0; id foo = (id)magicAddr;

WTF？

只是在特定的init方法中插入那行代码就会导致我通过数组的迭代失败“NSGenericException：Collection在被枚举时被突变”。 注释掉线会导致异常不发生。 此代码是单线程的。 这种行为是确定性的，并且一直反复重复，并且当我评论该线路时，它一直是不可复制的。 “foo”是一个虚构的变量，永远不会被再次引用。 没有其他代码引用“foo”。

这条线有副作用吗？ 将数字转换为（id）会产生一些副作用吗？

关于我在做什么的更多细节：

我跑了NSLog（@“self =％p，super =％p”，self，super）然后打印出“self = 0xa83dc50，super = 0xbfffe8d0”，引导我提出这个问题 我有_NO_IDEA_ 0xbfffe8d0值是什么或意味着什么。 我粘贴的行是在一个类的方法init2中，该类在对抛出异常的集合上引用了NSEnumerator。 该类不会改变集合，甚至不会引用该集合。

确切的代码:(删除，不相关或有趣）

---

好的，所以我仍然无法解释上面的行为。 我无法解释为什么堆栈上的4字节int是可以的，但是4字节的“id”是crashville。 但是我把这个代码运行了几百次，把所有随机废话都放进去了，我能够用其他值和语句触发崩溃。 总是确定性的，但没有清楚或可解释的模式，对于那些没有崩溃的东西。 Bizzare的东西，但不是最终的问题。

真正的问题？ 该集合来自[NSThread callStackSymbols]。 返回_NSCallStackArray。 这就是真正的斑马生活的地方。 关于那个伪集合有一些时髦的东西，但我无法告诉你究竟是什么。

修复？

[NSArray arrayWithArray: [NSThread callStackSymbols]]

通过修复，我的代码中没有随机垃圾的组合将触发枚举崩溃。 所以要小心。 如果您计划返回调用堆栈符号并将其视为数组，请进行复制。

课程？ 如果您调用[NSThread callStackSymbols]并希望将结果视为数组，请进行复制并获取真实数组。 否则，......“有龙”!!

The following line of code causes my program to break in a very strange way...

id foo = (id)0xbfffe8d0;

Yet, this is no problem:

int foo = (int)(id)0xbfffe8d0;

And even this is no problem:

int magicAddr = 0xbfffe8d0; id foo = (id)magicAddr;

W. T. F. ?

Just inserting that line of code inside a particular init method causes my iteration through an array to fail with "NSGenericException: Collection was mutated while being enumerated". Commenting the line out causes the exception not to happen. This code is single-threaded. The behavior is deterministic and has consistently reproduced over and over again and consistently non-reproduced when I comment the line out. "foo" is a made-up variable and is never referenced again. No other code refers to "foo".

Does that line have a side-effect? Does casting a number to an (id) have some side-effect?

More details on what I was doing:

I ran NSLog(@"self=%p, super=%p", self, super) and it printed out "self=0xa83dc50, super=0xbfffe8d0", leading me to ask this question I have _NO_IDEA_ what that 0xbfffe8d0 value is or means. The line I pasted is inside a method init2 for a class that has a reference to the NSEnumerator over the collection which throws the Exception. The class does NOT mutate the collection or even have a reference to the collection.

The exact code: (removed, not relevant or interesting)

---

OK, so I still can't explain the behavior above. I can't explain why a 4-byte int on the stack is ok, but a 4-byte "id" is crashville. But I ran this code a few hundred times putting all manor of random crap in, and I was able to trigger crashes with other values and statements. Always deterministic, but no clear or explainable pattern for stuff that crashed vs stuff that didn't. Bizzare stuff, but not the ultimate issue.

The real issue? The collection was from [NSThread callStackSymbols]. That returns _NSCallStackArray. That's where the real Zebra lives. There's something funky about that pseudo-collection, but I couldn't tell you what exactly.

The fix?

[NSArray arrayWithArray: [NSThread callStackSymbols]]

With the fix, no combination of random crap in my code will trigger the enumeration crash. So beware. If you plan to return the call stack symbols and treat them as an array, MAKE A COPY.

The lesson? If you call [NSThread callStackSymbols] and want to treat the result like an array, MAKE A COPY and get a real array. Else, .... "there be dragons" !!

最满意答案

编号id是指针类型的typedef ，并且指向指针没有副作用。 您的代码中还有其他一些错误，如果没有看到更多代码，就无法说出来。

0xbfffe8d0是指向堆栈中地址的指针。 在没有优化的情况下编译时，赋值0xbffe8d0值0xbffe8d0写入堆栈，但该值永远不会在任何地方读取。 因此它确实具有以下效果：（a）将该函数的堆栈帧大小增加4个字节，以及（b）改变函数代码的大小并抵消所有后续代码。 这些更改很可能导致程序中其他位置的错误出现或不出现。

No. id is a typedef for a pointer type, and assigning to a pointer has no side effects. You have some other bug in your code somewhere else, it's impossible to say without seeing more code.

0xbfffe8d0 is a pointer to an address in your stack. When compiled without optimizations, the assignment does write the value 0xbffe8d0 into your stack, but that value then never gets read anywhere. So it does have the effect of (a) increasing that function's stack frame size by 4 bytes and (b) changing the size of the function's code and offsetting all of the subsequent code. Most likely these changes are causing the bug elsewhere in your program to appear or not appear.