Objective c GCC编译器——bug还是未指定的行为？

当我在objective-c中对一个类的IVAR有冲突的定义时（不是在同一个文件中重新定义该类，而是用diff-IVAR命名同一个类），编译器不会发出警告或更好的错误。但是，这两组IVAR都可以通过相应文件中的适当方法使用。例如

Foo.m：

@interface foo {
int a;
}
- (int)method;
@end

@implementation foo

- (int)method {
    return a;
}

@end

Bar.m：

@interface foo {
float baz;
}

@end

@implementation foo (category)
- (float)blah {
    return baz;
}
@end

编译时没有警告或错误。这是故意的吗？这是未检查的错误吗？（对于记录，a和baz实际上是相同的内存位置。）

---

编辑：我要说的是iPhone操作系统，我相信它使用与64位MacOS相同的运行时。我认为你所做的就是类。

虽然显然是坏的，但在任何情况下，代码都应该在没有警告的情况下编译，因为编译器没有足够的信息知道如何警告。正确编译时，它只会生成64位的完全不同的链接器错误（这是新的Objective-C ABI的副作用，而不是直接来自非脆弱IVAR）

如果将

int main（）{}

添加到foo.m，然后使用命令行

gcc-arch x86_64 foo.m-lobjc

对其进行编译，链接错误就会消失，因为objc运行库提供了完成链接所需的空vtable符号

在编译过程中，将每个.m文件视为一个独立的编译单元。当编译器编译.m文件时，它只知道该.m文件中的内容、该.m文件中导入的任何内容提供的内容，以及（如果为其配置了项目）项目预编译头中定义的内容

因此，当你在bar.m中说：

@interface foo {
float baz;
}

@end

@implementation foo (category)
- (float)blah {
    return baz;
}
@end
int main() {}

编译器对foo.m中的声明没有概念。生成的代码描述了访问ivar baz的类foo上的一个类别。如果该类在链接时不存在，现在将抛出一个错误，考虑到您的foo.m和bar.m以及我添加的上述主函数，让我们尝试一些不同的编译：

gcc -arch i386 foo.m -lobjc
Undefined symbols:
  "_main", referenced from:
      start in crt1.10.6.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

这很有意义，因为我们没有在foo.m中定义main（）函数。64位编译也会这样做

gcc -arch i386 bar.m -lobjc

在没有警告的情况下编译和链接。要了解原因，请查看生成的符号（删除了十几个不相关的符号）：

因此，二进制文件在类

foo

上包含一个名为

category

的类别。没有链接错误，因为链接器实际上没有尝试解析类别。它假设类

foo

将在运行时解析类别之前神奇地出现

您可以使用ivar跟踪运行时的类/类别解析：

env OBJC_PRINT_CLASS_SETUP=YES ./a.out 
objc[498]: CONNECT: pending category 'foo (category)'
objc[498]: CONNECT: class 'Object' now connected (root class)
objc[498]: CONNECT: class 'Protocol' now connected
objc[498]: CONNECT: class 'List' now connected

因此，该类别被标记为挂起。只要

foo

存在，运行库就会将其挂起

现在，64位

gcc -arch x86_64 bar.m -lobjc
Undefined symbols:
  "_OBJC_IVAR_$_foo.baz", referenced from:
      -[foo(category) blah] in ccvX4uIk.o
  "_OBJC_CLASS_$_foo", referenced from:
      l_OBJC_$_CATEGORY_foo_$_category in ccvX4uIk.o
      objc-class-ref-to-foo in ccvX4uIk.o
ld: symbol(s) not found

链接错误是因为现代Objective-C ABI实际上出于各种原因导致发出适当的符号，例如变量和类别，包括添加有助于验证程序的元数据（在本例中就是这样）

没有编译错误（这是正确的行为），并且链接错误是有意义的。现在，将两者链接在一起如何

在32位的情况下，所有编译和链接都不会出错。因此，我们需要查看符号和ObjC调试喷口，以了解发生了什么：

gcc -arch i386 bar.m foo.m -lobjc
nm -a a.out
00001e0f t -[foo method]
00001dea t -[foo(category) blah]
00000000 A .objc_category_name_foo_category
00003070 S .objc_class_name_foo
env OBJC_PRINT_CLASS_SETUP=YES ./a.out 
objc[530]: CONNECT: attaching category 'foo (category)'
objc[530]: CONNECT: class 'Object' now connected (root class)
objc[530]: CONNECT: class 'Protocol' now connected
objc[530]: CONNECT: class 'List' now connected
objc[530]: CONNECT: class 'foo' now connected (root class)

啊哈！现在有一个类

foo

，运行时在启动时将该类别连接到该类。显然，返回

baz

ivar的方法将非常失败

64位链接器失败，但：

gcc -arch x86_64 bar.m foo.m -lobjc
Undefined symbols:
  "_OBJC_IVAR_$_foo.baz", referenced from:
      -[foo(category) blah] in ccBHNqzm.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

---

通过添加实例变量的符号，链接器现在可以捕获类被错误地重新声明的情况（如bar.m的

@interface

中所做的）.

因此，根据我最初的问题：这是编译器故意的行为还是未经检查的错误？同样，对于iPad来说，这是在“现代”运行时测试的，但在模拟器上测试，这意味着它实际上是i386，那么它会遵循上面定义的64位规则还是32位规则（当您使用这些术语而不是新的/旧的运行时）更重要的是，这种情况会在设备上发生变化吗？最后，就返回baz ivar而言，不会发生明显的故障，因为它与a的内存位置相同，如*（int*）所示&产生aThe值的baz可以并且确实在没有警告的情况下编译。它将在64位桌面编译和定位设备时导致链接错误，但链接正常（但运行错误）在模拟器中。如果您希望能够在

baz

和

a

中存储一个值，那么它将非常失败，因为在模拟器的运行时，这两者有效地共享存储空间。

gcc -arch x86_64 bar.m foo.m -lobjc
Undefined symbols:
  "_OBJC_IVAR_$_foo.baz", referenced from:
      -[foo(category) blah] in ccBHNqzm.o
ld: symbol(s) not found
collect2: ld returned 1 exit status