I can't find the search.h header file mentioned in spell.c, and hence the compiler can't find hcreate(), hsearch() and ENTRY.
Ref:
http://marcelotoledo.com/how-to-write-a-spelling-corrector/
https://github.com/marcelotoledo/spelling_corrector/blob/master/spell.c
The <search.h> header is a POSIX-standard header — and the library functions it declares include:
hash search (hsearch())
linear search (lsearch())
tree search (tsearch())
Those pages each list the set of relevant functions for a particular search. Note that binary search, aka bsearch(), is defined by the C standard rather than POSIX.
The functions were part of Unix SVR4 (and possibly other System V versions), and made it into the Single Unix Specification and hence POSIX too.
If your system doesn't support the header, then it isn't strictly POSIX compliant. You can certainly find implementations of the functions on the web (BSD, Linux — and probably other places too). You may be able to find a version to download for your system. (Macs have it already; I'd expect to find AIX, HP-UX, Solaris include it by default, too.)
Related
I was trying to read the man page for fstat, and I got fstat(2), fstat(3) and fstat(3P).
Having in the past used a system (2) command, I know the difference is that I have to write a prototype myself to announce the function (which is reflected in the fstat(2) man page).
But never have I seen that a function is both a C function (3) and a system function (2) at the same time. What would be the benefit of using one over the other? How would C even differentiate whether I am using (2) or (3).
Also, I understand that sys/stat.h is platform specific, so which of (2) and (3) would be safer to use for cross-platform? Since I don't see a prototype line in the Windows page example, I assume it is a (3)
Please explain this to be because I cannot wrap my head around why both would exist.
Web-based manpages are always a second-best option, since they can only show you a generic view of the interfaces. If you use the man command on your own system (at least for Unix-like systems), the result should reflect your actual installation, assuming you've correctly installed the documentation for your distribution.
Section 2 of the manual is intended for the description of system calls rather than standard library APIs. However, at least in the case of Linux documentation, section 2 is also used to describe the library wrappers around the system calls, which effectively documents the particular features implemented by the standard C library, normally glibc. In such cases, section 3P is used to document the to contain documentation extracted or adapted from the Posix standard. So if you want to write portable code, use only the features documented in section 3P. If you are happy to use all the extensions available to you on your system, use section 2.
man7.org and linux.die.net use different manpage repositories; on the latter, section 3P doesn't exist and the Posix programming manual is found in section 3. So https://www.man7.org/linux/man-pages/man3/fstat.3p.html and https://linux.die.net/man/3/fstat contain the same information. If you use a linux distribution, you'll probably find that man 3 fstat actually gives you the page from section 3p.
In any event, there is only one interface in the C library, which should conform to the Posix standard, but may extend it.
POSIX 2008 introduces several file system functions, which rely on directory descriptor when determining a path to the file (I'm speaking about -at functions, such as openat, renameat, symlinkat, etc.). I doubt if all POSIX platforms support it (well, at least the most recent versions seem to support) and I'm looking for a way to determine if platform supports such functions. Of course one may use autoconf and friends for compile-time determination, but I'm looking for a possibility to find out whether implementation supports -at functions dynamically.
The first that comes to my mind is a dlopen()/dlsym()/dlclose() combo; at least I've successfully loaded the necessary symbols from /usr/libc.so.6 shared library. However, libc may be (or is?) named differently on various platforms. Is there a list of standard locations to find libc? At least on Linux /lib/libc.so appears to be not a symbolic link to shared library, but a ld script. May be there exist some other way to examine during runtime if a POSIX function is supported? Thanks in advance!
#define _GNU_SOURCE 1
#include <dlfcn.h>
#include <stdio.h>
int main ()
{
void * funcaddr = dlsym(RTLD_DEFAULT, "symlinkat");
/* -----------------------^ magic! */
printf ("funcaddr = %p\n", funcaddr);
}
Output:
funcaddr = 0x7fb62e44c2c0
Magic explanation: your program is already linked with libc, no need to load it again.
Note, this is actually GNU libc feature, as hinted by _GNU_SOURCE. POSIX reserves RTLD_DEFAULT "for future use", and then proceeds to define it exactly like GNU libc does. So strictly speaking it is not guaranteed to work on all POSIX systems.
I'm looking at the Ruby MRI code for File#flock. The documentation states that it's "Not available on all platforms.", but doesn't state which. If I should venture a guess, old FAT file systems might not have locking, but I would like to not be guessing.
Digging a bit into the implementation takes me to rb_file_flock(VALUE obj, VALUE operation), which in turn calls rb_thread_flock(void *data). This simply wraps a call to flock from sys/file.h. However, it seems that this implementation may or may not be available:
#ifdef HAVE_SYS_FILE_H
# include <sys/file.h>
#else
int flock(int, int);
#endif
However, I can't figure out where HAVE_SYS_FILE_H is defined (In a build-script perhaps?), so I don't know which platforms would enable it.
So, for my question(s): Which platforms could I expect HAVE_SYS_FILE_H to be defined for. And provided that it is defined and thus sys/file.h available, can I expect file locking to work?
flock is a BSD and Linux extension function:
CONFORMING TO
4.4BSD (the flock() call first appeared in 4.2BSD). A version of flock(), possibly implemented in terms of fcntl(2), appears on most UNIX systems.
Unix specification does require advisory file locking to be implemented in terms of fcntl(F_SETLK):
Record locking shall be supported for regular files, and may be supported for other files.
As per Wikipedia there are many variants of standard C library based on operating system and compilers.
Ref: http://en.wikipedia.org/wiki/C_standard_library
But I want to understand that how plenty of functions which are declared in different headers(eg: stdio.h, string.h, stdlib.h etc. ) are defined in single library. Is the source code file is same for all these header files or there are different libraries for stdio.h, string.h etc? As I am beginner to programming I don't know if multiple source code files can generate a single library like executable. If it is possible then I can understand that libc contains definition of all the standard header files. Where can I see the source code of standard C library?
Is it a static library or dynamic library? If both versions are present in my environment(OS/IDE) which one get linked when I include any standard header file in my source code. Is it IDE dependent? But in case of gcc, programmer does not include libc explicitly.
Is libc a standard name for standard C library?
In windows operating system/environment is it already present or not? If it is present what is the name of it(is it libc only)?
Is there any other standard C library like libm?
Generally speaking, a header (.h) file contains the declarations of functions and variables. Implementation files (.c) contain the actual implementation of the declared functions. Since several implementation files can be translated and linked into a single library binary, you can have one library with multiple headers. Many C library implementations are Open Source, and you can look at their source code at their relative project pages. GNU libc and RedHat newlib are the most prominent. I am sure people will add more in comments.
Implementation defined. You can translate the very same sources into either a static or a dynamic library. It is not uncommon to have both versions installed on your system. Since virtually every executable requires libc, it is usually added to the linker input by default so you don't have to add -lc to every command line.
No. The standard name for the standard C library is "The Standard C Library". Note that virtually all implementations of the standard library extend the library with non-standard functions. These remain non-standard, even if they come as part of the standard library. (alloca() springs to mind.)
MSVCRT.dll or somesuch, if I remember correctly.
libm stands for the math section of the standard library, which is not added to the linker input by default as it is seldom required. There is only one standard C library, the one described by the ISO/IEC 9899 language standard (hence the name). There are many other libraries that can readily be assumed to be present on a given system, but only what's described in the ISO/IEC documents is "the standard".
I was searching for the source code of the C standard libraries. What I mean with it is, for example, how are cos, abs, printf, scanf, fopen, and all the other standard C functions written, I mean to see their source code.
So while searching for this, I came across with GLIBC, but I don't know what it actually is. It is GNU C Library, and it contains some source codes, but what are they actually, are they the source code of the standard functions or are they something else? And what is it used for?
Its the implementation of Standard C library described in C standards plus some extra useful stuffs which are not strictly standard but used frequently.
Its main contents are :
1) C library described in ANSI,c99,c11 standards. It includes macros, symbols, function implementations etc.(printf(),malloc() etc)
2) POSIX standard library. The "userland" glue of system calls. (open(),read() etc. Actually glibc does not "implement" system calls. kernel does it. But glibc provides the user land interface to the services provided by kernel so that user application can use a system call just like a ordinary function.
3) Also some nonstandard but useful stuff.
"use the force, read the source "
$git clone git://sourceware.org/git/glibc.git
(I was recently pretty enlightened when i looked through malloc.c in glibc)
There are several implementations of the standard. Glibc is the implementation that most Linuxes use, but there are others. Glibc also contains (as Aftnix states) the glue functions which set up the scene for jumps into the kernel (also known as system calls). So many of glibc's 'functions' don't do the actual work but only delegate to the kernel.
To read the source of Glibc, just google for it. There are myriad sites which carry it, and also several variations.
Windows uses Microsoft's own implementation, which I believe is called MSVCR.DLL. I doubt that you will find the source code to that library anywhere. Also note that some functions which a Linux hacker might think of as 'standard', simply don't exist on Windows (notably fork). The reverse is also true.
Other systems will have their own libc.
The glibc package contains standard libraries which are used by multiple programs on the system. In order to save disk space and memory, as well as to make upgrading easier, common system code iskept in one place and shared between programs. This particular package contains the most important sets of shared libraries: the standard C library and the standard math library. Without these two libraries, a Linux system will not function. The glibc package also contains national language (locale) support.
Yes, It's the implementation of standard library functions.
More specifically, it is the implementation for all GNU systems and in almost all *NIX systems that use the Linux kernel.
Here are a few "hands-on" points of view:
it implements the POSIX C API on top of the Linux kernel: What is the meaning of "POSIX"?
it contains several assembly hand-optimized versions of ANSI C functions for several different architectures, e.g. strlen:
sysdeps/x86_64/strlen.S
sysdeps/aarch64/strlen.S
how to modify its source, recompile and use it understand it better: How to compile my own glibc C standard library from source and use it?
how to GDB step debug it with QEMU and Buildroot: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/9693c23fe6b2ae1409010a1a29ff0c1b7bd4b39e#gdbserver-libc