ncurses get_wch() function undeclared - c

I try to check the output of the get_wch function from the ncurses library, on Archlinux install.
But when I call the function, I got this GCC error:
main.c:6:15: warning: implicit declaration of function "get_wch";
I linked the lib like my GCC command-line suggest:
gcc main.c -lncursesw -o exec
I have also check that ncurses is installed:
core/ncurses 6.2-1 [installed]
multilib/lib32-ncurses 6.2-1 [installed]
And I see the header generated at the lib compile time that allow me to use "widec" functions, when I list header files in the "usr/include" directory.
#include <curses.h>
int main() {
initscr();
int test = 0;
int result = get_wch(&test);
printf("Caractère : {} / Function code : {}\n", test, result);
endwin();
return 0;
}
I don't understand how to use this lib. And the available "documentation" seems to play against me...

The gcc warning
main.c:6:15: warning: implicit declaration of function "get_wch";
tells you that there is no function prototype for get_wch. X/Open Curses specified all of the wide-character functions conditionally (to avoid breaking old programs). That's summarized in the ncurses manual page:
You must also enable the wide-character features in the header
file when compiling for the wide-character library to use the
extended (wide-character) functions. The symbol which enables
these features has changed since XSI Curses, Issue 4:
Originally, the wide-character feature required the symbol
_XOPEN_SOURCE_EXTENDED but that was only valid for XPG4
(1996).
Later, that was deemed conflicting with _XOPEN_SOURCE defined
to 500.
As of mid-2018, none of the features in this implementation
require a _XOPEN_SOURCE feature greater than 600. However,
X/Open Curses, Issue 7 (2009) recommends defining it to 700.
Alternatively, you can enable the feature by defining
NCURSES_WIDECHAR with the caveat that some other header file
than curses.h may require a specific value for _XOPEN_SOURCE
(or a system-specific symbol).
The prototype for get_wch uses wint_t (an integer which can hold a "wide character" such as Unicode). The manual page lists these types which are used in the wide-character ncursesw library (and function prototypes): cchar_t, wchar_t and wint_t
If you want to use a function prototype using any of those types, your program should turn on the feature. As mentioned before, defining NCURSES_WIDECHAR is simplest.

Related

implicit declaration of function ‘getline’ warning thrown in one code, but not in another

THIS QUESTION IS NOT HOW TO REMOVE THE WARNING
I am writing a shell. I referred this source. I used the same headers (in the same order), as he did, in my code.
When compiling his code, I do not get any warnings for implicit declaration of getline. But when I compile mine, it does get thrown.
The man page suggests to use #define _GNU_SOURCE, and adding that removed the warning from my code.
So why was no warning thrown for the code in the blog, as he did not use #define _GNU_SOURCE?
Here is the minimal code (I copied all the headers as I mentioned above)
// #define _GNU_SOURCE
#include <sys/wait.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
int main()
{
ssize_t bytes_read;
size_t input_buffer_size = 1024;
char *user_input = (char *)malloc(input_buffer_size * sizeof(char));
while (1)
{
printf("> ");
bytes_read = getline(&user_input, &input_buffer_size, stdin);
printf("%s\n", user_input);
}
return 0;
}
And here is the compilation process I used...
gcc -std=c11 -o bin/shell src/shell.c
Here is the error that I get if I leave the first line commented.
src/shell.c: In function ‘main’:
src/shell.c:18:18: warning: implicit declaration of function ‘getline’ [-Wimplicit-function-declaration]
18 | bytes_read = getline(&user_input, &input_buffer_size, stdin);
| ^~~~~~~
It appears that the person who wrote the tutorial you're referring to, did not supply any special compilation options when they were testing their code. I see only one compilation command anywhere on that page, and it is gcc -o main main.c. Thus, they got GCC's defaults, which, typically, make getline available on computers that have it.
You, however, used the compiler flag -std=c11 when you compiled your code. One of the effects of this flag is that GCC directs the C library's headers to declare only the functions, constants, variables, etc. that are specified by ISO C2011. (Depending on which C library you're using, this directive may or may not have any effect — but Ubuntu uses the GNU C library, which implements it thoroughly.) getline is not part of ISO C2011, so it is not declared and you get an "implicit declaration" diagnostic when you try to use it.
Use of the hyperconformant -std=cXX modes is almost always a mistake. There are exactly three differences between -std=cXX and -std=gnuXX and none of them is desirable in practice:
As discussed above, it directs the headers not to declare anything that's not part of the specified revision of ISO C. As you saw for yourself, this is almost never what you want when writing a nontrivial C program. It also has a nasty tendency to break library headers — both third-party headers and the C library's own headers — because they are rarely, if ever, tested in this mode.
It disables "system-specific predefined macros" that pollute the user namespace (e.g. linux, unix, arm). This is abstractly desirable but, like #1, has a nasty tendency to break library headers that are rarely, if ever, tested in this mode.
It enables trigraphs, which are a kludge to make C work with "national variants" of ASCII that are missing some punctuation. These are so rarely used and cause so much practical confusion that they were actually stripped out of C++ 2017 (not C 2017, though).
To compile your own code with a reasonably picky level of conformance diagnostics, but not risk breaking library headers, there is a better combination of options:
cc -std=gnuXX -g -Og -Wall -Wextra -Wpedantic -Wstrict-prototypes -Wwrite-strings
(Pick a suitable XX; if you have no reason to choose anything else, I'd go with 11.) You may or may not want to add a -D switch for one of the _xxx_SOURCE feature selection macros; explaining how those work and how to choose one is a whole question in itself.

Why are string functions working without including the string library?

In my code, I call functions from the string.h library (specifically, strcmp()), but I forgot to add the string library. Even without including the string library, my code compiles and runs properly as if I had included the string library.
What is happening?
A header file (e.g., string.h) only includes function declarations: that is, the return type and types and number of parameters.
The functions are defined in the C library (which is linked against your code by default), so they are are available to you whether or not you #include <string.h>. However, if you fail to #include the header file, the compiler might warn you about missing function declarations, and it can also cause problems if the return type of a function is other than int (the default for functions not otherwised declared in C).
Starting with the 1999 ISO C standard, calling a function with no visible declaration is a constraint violation, requiring a diagnostic. The diagnostic may be a non-fatal warning.
Some C compilers do not enforce the newer C99 rules by default. For example, until recently gcc's default behavior was -std=gnu89, which supports the 1989/1990 C standard with GNU-specific extensions.
Under the older rules, if you call a function with no visible declaration, an implicit declaration is created assuming that the function returns int and expects the number and types of arguments you've passed it. If that assumption is incorrect, the call's behavior is undefined. It happens that strcmp() returns an int, so if the compiler accepts the call you'll probably get away with it.
You should find out how to get your compiler to at least warn you about calls to undeclared functions. Once you've confirmed that it will do so, you should add the requires #include <string.h> to your code.
Note that the #include directive only includes the header file that declares strcmp and other standard functions, not the library. The definitions of those functions (the code that implements them) is commonly included as part of the C standard library. Linking your program to the standard library is handled by the linker, not by the compiler, and it's usually done implicitly (because you asked to compile and link a C program). (The math library, depending on the implementation, might not be linked automatically, but the implementation of the string functions almost always is.)
The string library is in fact included if you include the stdio library. But the stdio does not include the string library(not directly)
By default compiler include all necessary header file and program will successfully run.
Which Compiler you are using ?
you should use C99 compiler with -strict flags and -error flags then compiler will give you error if you call a function without including header file..
Error will look like this
implicit declaration of strcmp() found

Is there any default header file in GNU

When I am going through a code snippet I have seen some functions like
#include <stdio.h>
int main() {
printf( "Upper case of a is %c\n", toupper('a'));
printf( "Upper case of 9 is %c\n", toupper('9'));
printf( "Upper case of g is %c\n", toupper('g'));
return 0;
}
being used in the source file without any header file being included.
So is there any default header file that gets added to source when compiling. I am using GNU C.
Please don't mind if the syntax of the function is wrong as that is not the important point.
No, there are no implicit #include directives.
What you're probably running into is that, prior to the 1999 ISO C standard, C permitted functions to be called with no visible declaration. The compiler would assume that the called function returns int and takes arguments compatible with the (promoted) arguments passed in the call.
gcc by default supports the 1990 ISO C standard plus GNU-specific extensions.
If you compile with something like gcc -std=c99 -pedantic, you'll get warnings about calls to functions with no visible declarations. (Use -std=gnu99 if you need GNU-specific extensions as well.)
Calling undeclared functions was a bad idea even before the 1999 standard. You should correct your code so there's a visible declaration (probably via a #include for the appropriate header) for each function you call or otherwise refer to.
Your original question asked about toUppercase, which is not a standard function; it may or may not be defined somewhere else.
Your revised question uses toupper, which is a standard C function declared in <ctype.h> and defined in the standard C library.
It's not surprising that you can get away with calling toupper with no visible declaration -- but you should still add
#include <ctype.h>
to the top of your source file.
Before you do that, try compiling with gcc -std=c99; you should get a warning.
One more thing: It's important to keep in mind that headers and libraries are two different things.
Headers, like <stdio.h> and <stdlib.h> are generally text files containing just declarations of functions and other entities specified by the C standard library.
Libraries, which have system-specific names like, for example, libc.so, contain the actual executable code that implements those functions.
Headers are handled by the compiler; libraries are handled by the linker.
There are generally no default headers; every header you use has to be explicitly #included, either directly or indirectly. libc.so (or whatever it's called) is typically linked by default; you don't have to specify it. (Though for the functions declared in <math.h>, you often have to specify -lm to link the corresponding library.)
As forum people are asking not to discuss in comments so i have no other option than replying to " Keith Thompson" last post. I am not sure what you meant by c standard library. look here
C standard library
It clearly says 27 header files are part of standard library and stdlib.h is one of them. See my point is not to argue with you. I am trying to have clarity in mind. You are saying something like libc.so as standard library but the wikipedia clearly states something else and now i am totally confused.

Cannot interpret compiler warning

My compiler (gcc) throws warnings (not errors!) on the line which declares fp:
int fd = open("filename.dat", O_RDONLY);
FILE* fp = fdopen(fd, "r"); // get a file pointer fp from the file descriptor fd
These are the warnings:
main.c: In function ‘main’:
main.c:606: warning: implicit declaration of function ‘fdopen’
main.c:606: warning: initialization makes pointer from integer without a cast
I do not understand these warnings since the return value of fopen is a FILE*. What is the mistake I am making here?
EDIT: I am including stdio.h (and I am also on Linux).
Short answer: use -std=gnu99 when compiling, the usual standard is non-POSIX and does not have fdopen.
warning: implicit declaration of function ‘fdopen’
Means you have forgot to include the header file which the declaration of fdopen() resides in. Then an implicit declaration by the compiler occurs - and that means the return value of the unknown function will be assumed to be int - thus the second warning. You have to write
#include <stdio.h>
Edit: if you properly include stdio.h, then fdopen() might not be available on the system you're targeting. Are you on Windows? This function is POSIX-only.
Edit 2: Sorry, I really should have perceived this. C99 means the ANSI C99 standard - and standard C doesn't force the concept of file descriptors in order to support non-POSIX systems, so it provides fopen() only. fdopen() is related to file descriptors, so it's POSIX-only, so it's not part of standard C99. If you use the -std=gnu99 switch for GCC, it gets rid of the standard's restrictions and lets in the POSIX and GNU-only extensions, essentially fixing your problem.
#define _XOPEN_SOURCE 600
#include <stdio.h>
This conforms perfectly with strict c99
gcc -std=c99 -pedantic -Wall -Wextra -Werror
You are not including #include <stdio.h> in C the compiler therefore "guesses" the declaration of the function you're trying to call. (Taking the parameters you've based and using int as return value). Usually you don't want such guesses therefore the compiler warns you.
Solution: Add proper #includes.
The fdopen function is not part of the C standard and is not available as part of the standard headers if you compile in standard C mode. So you either need to use -std=gnu99 instead of -std=c99 to compile your source or declare the function yourself.
There's a good explanation for the compiler's diagnostic in #H2CO3's answer, so let's only look on the why of things: if you're using glibc (and you probably are), certain POSIX functions may require specific feature test macros to show up.
In particular, you may need to put the following line:
#define _POSIX_SOURCE
// or #define _XOPEN_SOURCE
before
#include <stdio.h>
Certain compilers (such as gcc) also have command line options to the same effect (all the gnu* standards options in gcc).

Can an ANSI C-compliant implementation include additional functions in its standard library?

Is an ANSI C-compliant implementation allowed to include additional types and functions in its standard library, beyond those enumerated by the standard? (An ideal answer would reference the relevant part of the ANSI standard.)
I ask particularly because Mac OS 10.7 declares the getline function in stdio.h, even when compiling with gcc or clang using the -ansi flag. This breaks several older programs that define their own getline function. Is this a fault of Mac OS 10.7? (The man page for getline on Mac OS 10.7 says that getline conforms to the POSIX.1 standard, which came in 2008.)
Edit: To clarify, I find it odd that including stdio.h in an ANSI C89 program on Mac OS 10.7 also pulls in the declaration for the getline function, since getline is not one of the functions enumerated in the K&R (and presumably ANSI) description of stdio.h. In particular, attempting to compile noweb:
gcc -ansi -pedantic -c -o notangle.o notangle.c
In file included from notangle.nw:28:
getline.h:4: error: conflicting types for ‘getline’
/usr/include/stdio.h:449: error: previous declaration of ‘getline’ was here
Is it a bug in Mac OS 10.7 includes the declaration of getline in stdio.h even when compiling for the ANSI C89 standard?
From section 7.1.3 paragraph 2 of n1570 (which is a draft of C1x):
No other identifiers are reserved.
This is the part that means getline shouldn't be defined by the <stdio.h>, since it's not a reserved identifier according to the spec. So if your library defines getline in <stdio.h>, it's not technically compliant with the C standard...
However, you should be able to use the feature test macros to cause getline to be undefined in <stdio.h>.
#undef _POSIX_C_SOURCE
#define _POSIX_C_SOURCE 200112L
#include <stdio.h>
This will give you only the definitions from the older POSIX standards. This won't work on some GNU C++ implementations, which is ExTrEmeLY fruSTRaTiNG for some folks.
The relevant section of the manpage is (taken from a glibc manpage, sorry...)
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
getline(), getdelim():
Since glibc 2.10:
_POSIX_C_SOURCE >= 200809L || _XOPEN_SOURCE >= 700
Before glibc 2.10:
_GNU_SOURCE
This part of the manpage tells you which macros need to be defined to which values in order to get the definition. My bet is that _POSIX_C_SOURCE is already defined by your compiler to 200809L.
The idea of feature test macros is that if you define your macros, like _POSIX_C_SOURCE, _BSD_SOURCE, _XOPEN_SOURCE, etc. to the values you want, you won't need to worry about new library functions clashing with your existing functions. There is also _GNU_SOURCE, which turns everything on if you use glibc, but I suggest giving that macro a wide berth.
Yes, a compliant implementation is allowed to define additional identifiers, including functions, as long as they are one of the reserved identifiers in the standard. For example:
All identifiers that begin with an underscore and either an uppercase letter or another
underscore are always reserved for any use;
All identifiers that begin with an underscore are always reserved for use as identifiers
with file scope in both the ordinary and tag name spaces;
All external names that begin with is, to, str, mem or wcs followed by a lowercase letter;
In addition there are names that are reserved only if you include certain headers; for example, if you include <errno.h> then it can define any macro starting with E followed by a digit or uppercase letter.
However, getline() is not such a reserved name, and a compliant implementation must make it available for the programmer's own use.

Resources