2015-06-20 79 views
-1

出于某种原因,-std = C99是保持GCC无法看到)功能wborder_set的声明((其居<curses.h>我使用-std时= C99

#include <curses.h> 
#include <locale.h> 

int main(int argc, char* argv[]){ 
    initscr(); // start ncurses 
    cbreak(); // don't wait for lf to getch 
    noecho(); // don't copy entered characters 
    nonl(); // use /r/l 
    clear(); // clear the screen! 

    setlocale(LC_CTYPE, ""); 

    int ySize, xSize; 
    getmaxyx(stdscr, ySize, xSize); 
    WINDOW *upperWin = newwin(ySize, xSize, 0, 0); 

    // magic utf encodings for window border 
    wborder_set(upperWin, "\u1234", "\u1234", "\u1234", "\u1234", 
      "\u1234", "\u1234", "\u1234", "\u1234"); 
    wrefresh(upperWin); 
    getch(); 
    return 0; 
} 
只获得了一个隐含的声明错误

gcc test.c -lncursesw -o cursestest编译正常!但是,如果我编译

gcc test.c -std=c99 -lncursesw -o cursestest

它回复,

cursescurses.c: In function ‘main’: cursescurses.c:18:7: warning: implicit declaration of function ‘wborder_set’ [-Wimplicit-function-declaration] wborder_set(upperWin, "\u1234", "\u1234", "\u1234", "\u1234",

这使我相信,我不能相信这是正确的连接wborder_set。

为什么会发生这种情况?

+0

aha! “ ”以下支持宽字符(多字节)的EXTENDED XSI Curses调用尚未实现:... wborder_set()...“ 所以即使函数是在手册页中定义的,它也不会实际上存在。 D'哦。 –

+0

在包含任何头以显示声明之前,您必须定义'_XOPEN_SOURCE_EXTENDED'。 – cremno

+0

这是在Linux上吗?我发现在Linux上,像-std = c99这样的选项倾向于将头文件限制为最小的c99模式,并禁用任何可能的扩展,如各种POSIX功能。 – Rhialto

回答

0

事实证明,问题是我包含了<curses.h>的错误版本。函数wborder_set实现unicode,并且需要ncurses库的Unicode/wide char扩展,我在#include <ncursesw/curses.h>中包含了该扩展。通过这种替换,程序按预期编译。

1

您的<curses.h>似乎没有包含函数的原型。规则在C99中改变了:使用没有声明的函数不再被允许。之前,他们将假定返回int

这与链接没有任何关系,但这是一个关于编译器期望函数返回某种类型的问题。

+0

函数'wborder_set'在curses.h中声明;那么我可以忽略那个警告,并期望它像c89一样工作吗?我是否需要将curses.h中的原型复制到我的代码文件中? –

+0

@sig_seg_v,不,如果代码如您在此给出的那样,编译器不会找到该函数的声明。您不应该忽略这些警告,它们表明您的工具链中的某些内容是错误的。 –

1

定义_XOPEN_SOURCE_EXTENDED会有所帮助,但Linux(像大多数系统一样)存在与标准冲突的扩展形式以及对标准的不同解释。所以...对于Linux来说,这个通用的创可贴是从定义_GNU_SOURCE开始的(它开启了适当的X/Open定义为事后考虑)。

如果您的ncurses配置包含reasonably currentncursesw5-config脚本,它将添加该-D选项。

相关问题