使用atoi时的依赖和错误答案

【问题标题】：Dependencies and errors when using atoi使用atoi时的依赖和错误
【发布时间】：2014-06-23 14:11:43
【问题描述】：

我的任务是重构一个非常古老的项目，而在最近几天我正在检查可执行文件的依赖关系，因为由于某些原因，它们自 2009 年以来发生了变化，从 4 变为 14。更具体地说，我的工作是保持 2009 年之前的依赖关系，但代码的更改一直持续到今天。

我找到了导致问题的指令。这是项目使用的库中的一个函数：

chain(str, pps)
    char *pps;
    char *str;
{
    int pp = 0;
    pp = atoi(pps);
    // ic sunt leones.

如果我用 0、1 或 3 之类的整数赋值来注释或替换 atoi，则库编译正常，但使用此 .lib 的可执行文件会给我以下错误：

nafxcw.lib(wincore.obj) : 错误 LNK2001: 无法解析的外部符号 __imp__InitCommonControls@0 nafxcw.lib(wincore.obj) : 错误 LNK2001: 无法解析的外部符号 __imp__DragAcceptFiles@8 nafxcw.lib(appcore.obj) : 错误 LNK2001: 无法解析的外部符号 _ClosePrinter@4 nafxcw.lib(appcore.obj)：错误 LNK2001：无法解析的外部符号 _DocumentPropertiesA@24 nafxcw.lib(appcore.obj) : 错误 LNK2001: 无法解析的外部符号 _OpenPrinterA@12 nafxcw.lib(filecore.obj) : 错误 LNK2001: 无法解析的外部符号 __imp__SHGetFileInfoA@20 nafxcw.lib(filecore.obj) : error LNK2001: unresolved external symbol _GetFileTitleA@12

否则，如果我使用不同的值进行赋值，例如 2、4 或每隔一个整数，则一切都可以正确编译并正常工作。

有什么建议吗？这里发生了什么事？为什么会有这种奇怪的行为？

编辑：显然问题不在于 atoi。如果我使用自制函数来执行任何操作并接受 char* 并返回 int 或直接用 int 替换函数链的第二个参数并直接分配它，我仍然会收到相同的错误。

【问题讨论】：

“我的工作是保持 2009 年之前的依赖关系，但代码的更改一直持续到今天”——听起来你需要找一份新工作。软件更改 - 试图在这种时间范围内保持静态可能是一场失败的战斗，或者是各种安全/性能/功能灾难的秘诀......
建议：与 /VERVOSE 链接，包括错误和解决方法，并区分跟踪。很有可能会出现有用的东西。

标签： c++ c visual-c++

【解决方案1】：

你可以试试这个：

include ('limits.h');

int my_getnbr(char *str)
{
  int   i;
  long  nbr;
  int   neg;

  neg = 0;
  nbr = 0;
  i = 0;
  if (str[0] == '-')
    {
      neg = 1;
      str++;
    }
  while (str[i] >= '0' && str[i] <= '9')
    {
      nbr = nbr * 10 + (str[i++] - '0');
      if (nbr > INT_MAX)
    return (0);
    }
  return (neg ? (int)nbr * -1 : (int)nbr);
}

这只是一个自制的atoi之类的。

编辑：由 Alter Mann 编写的 INT_MAX。编辑之二：如果 (nbr > INT_MAX) 再次由 Alter Mann :)

【讨论】：

永远不要使用2147483647，INT_MAX在limits.h中定义
if ((!neg && nbr > INT_MAX) || (neg && nbr > INT_MAX))和if (nbr > INT_MAX)是一样的，同样你需要控制一个以str[0] == '+'开头的字符串;)
感谢您的建议，但我已经尝试过使用自制的 atoi，我什至尝试将函数的第二个参数直接替换为 int，但结果是相同的。 :( PS：我已经编辑了问题以避免使用自定义 atoi 回答，据我所知，不幸的是问题不是 atoi :(

【解决方案2】：

我能想到的唯一一件事是简化的函数正在被编译不存在，然后链接器很有帮助地假设库中没有可链接的代码，因此它被删除了，不幸的是是唯一强制包含这些 MFC 库的东西。

我不知道为什么它甚至需要 OpenPinter 之类的东西——它包含在 winspool.h（通过 windows.h）中，只是说听起来你有一个基于 MFC 的令人讨厌的混乱需要解决。由于它依赖于以特定顺序指定的特定包含，因此它从来都不是很好的 WRT 整洁构建。

【讨论】：