(K&R) 内部名称的至少前 31 个字符是重要的?

发布于 2024-08-16 12:54:31 字数 242 浏览 1 评论 0原文

从字面上看,这是有道理的,但是变量名的重要字符到底意味着什么?

我是一个使用 K&R 的 C 初学者。这是本书的直接引用:

“内部名称的至少前 31 个字符很重要。对于函数名称和外部变量,该数字可能小于 31,因为外部名称可能由语言无法控制的汇编程序和加载程序使用。对于外部名称,标准仅保证 6 个字符和一个大小写。”

顺便问一下,“单一案例”是什么意思?

When taken literally, it makes sense, but what exactly does it mean to be a significant character of a variable name?

I'm a beginning learner of C using K&R. Here's a direct quote from the book:

"At least the first 31 characters of an internal name are significant. For function names and external variables, the number may be less than 31, because external names may be used by assemblers and loaders over which the language has no control. For external names, the standard guarantees only for 6 characters and a single case."

By the way, what does it mean by "single case"?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

趴在窗边数星星i 2024-08-23 12:54:31

Single Case 通常表示“小写”。除了在某些操作系统中它表示“大写”之外。关键是混合大小写并不能保证有效。

abcdef

ABCDEF

仅情况不同。这不能保证有效。

“重要性”问题是有多少个字母可以相同。

假设我们只有 6 个重要字符。

a_very_long_name

a_very_long_name_thats_too_similar

看起来不同,但前 16 个字符是相同的。由于只有 6 个显着,因此它们是相同的变量。

Single Case usually means "lower case". Except in some OS's where it means "upper case". The point is that mixed case is not guaranteed to work.

abcdef

ABCDEF

differ only in case. This is not guaranteed to work.

The "Significance" issue is one of how many letters can be the same.

Let's say we only have 6 significant characters.

a_very_long_name

a_very_long_name_thats_too_similar

Look different, but the first 16 characters are the same. Since only 6 are significant, those are the same variable.

朕就是辣么酷 2024-08-23 12:54:31

它意味着你所害怕的东西。对于外部名称,采用当时的 C 标准 K&R 第 2 版。确实只给出了六个不区分大小写的字符!因此,您不能将 afoobaraFooBaz 作为独立的实体。

这种荒谬的限制(用于适应现在早已不复存在的遗留链接器)不再与任何环境相关。 C99 标准为外部名称提供了 31 个区分大小写的字符,为内部名称提供了 63 个区分大小写的字符,并且实践中常用的链接器支持更长的名称。

It means what you fear it means. For external names, the C standard at the time K&R 2nd ed. was written really does give only six case-insensitive characters! So you can't have afoobar and aFooBaz as independent entities.

This absurd limitation (which was to accommodate legacy linkers now long-gone) is no longer relevant to any environment much. The C99 standard offers 31 case-sensitive characters for external names and 63 internally, and commonly-used linkers in practice support much longer names.

彩虹直至黑白 2024-08-23 12:54:31

这只是意味着,如果您有两个名为

abcdefghijklmnopqrstuvwxyz78901A

abcdefghijklmnopqrstuvwxyz78901B 的变量,

则不能保证它们将被视为不同的单独变量...

It just means that if you have two variables named

abcdefghijklmnopqrstuvwxyz78901A,

and

abcdefghijklmnopqrstuvwxyz78901B,

that there is no guarantee that will be treated as different, separate variables...

十年不长 2024-08-23 12:54:31

这意味着 :

foobar1
foobar2

可能是相同的外部名称,因为只需要考虑前 6 个字符。单大小写是指名称不需要区分大小写。

请注意,几乎所有现代链接器都会考虑更长的名称,但仍然存在限制,具体取决于链接器。

It means that :

foobar1
foobar2

might be the same external name, because only the first 6 characters need be considered. The single case means that upper and lower case names need not be distinguished.

Please note that almost all modern linkers will consider much longer names, thogh there will still be a limit, dependent on the linker.

欢烬 2024-08-23 12:54:31

您好,

这种有限符号解析的问题之一发生在链接时。

多个库中可以存在具有相同名称的多个符号,链接编辑器通常只采用它找到的第一个与其要查找的内容相匹配的符号。

因此,使用上面 S.Lott 的示例,如果您的链接编辑器正在搜索符号“a_very_long_name”,并且在其搜索路径上找到一个包含符号“a_very_long_name_thats_too_similar”的库,它将采用这个。即使在命令中指定了包含所需符号(即“a_very_long_name”)的库,也会发生这种情况。例如,将库指定为:

-L/my/library/path -lmy_wrong_lib -lmy_correct_lib

现在有编译器选项,或更准确地说是编译时选项,它们会传递到链接编辑器,强制搜索链接路径中的多个符号。这些通常会在链接时作为错误引发。

此外,许多编译器(例如 gcc)将默认为这种行为。您必须显式启用多个定义,以允许链接编辑器在找到符号的多个定义时继续进行,而不会引发致命错误。

顺便说一句,我强烈建议结合 Clovis Tondo 的书“C 答案来完成练习本书第二版。”。

这样做确实有助于让 C 牢牢记住。

HTH

欢呼,

G'day,

One of the problems with this limited symbol resolution occurs at link time.

Multiple symbols with the same name can exist across several libraries and the link editor usually only takes the first one it finds that matches what it is looking for.

So, using S.Lott's example from above, if your link editor is searching for the symbol "a_very_long_name" and it finds a library on its search path that contains the symbol "a_very_long_name_thats_too_similar" it will take this one. This will happen even if the library that contains the symbol that you want, i.e. "a_very_long_name" has been specified in your command. For example specifying the libraries as:

-L/my/library/path -lmy_wrong_lib -lmy_correct_lib

There are now compiler options, or more correctly compile time options which are passed through to the link editor, which enforce a search for multiple symbols in your link path. These are then usually raised as errors at link time.

In addition, many compilers, e.g. gcc, will default to such behaviour. You have to explicitly enable multiple definitions to allow the link editor to proceed without raising a fatal error if it finds multiple definitions for a symbol.

BTW I'd highly recommend working through the exercises in conjunction with Clovis Tondo's book "The C Answer Book 2nd ed.".

Doing this really helps make C stick in your mind.

HTH

cheers,

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文