Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
there is a part about UNIX system functions in R&K C programming guide.
there are system calls like read(), write(), open() or etc ,while we can use scanf(), printf(), fopen() or other c library functions to do the same work.
so what do we need C library functions instead of them?
why do we need to know and use UNIX system functions in C programming while we have that functions in C library?
The functions from the standard library provide your program an operating system independent interface to have the system perform tasks for you. So they are not UNIX specific, although they first appeared with many UNIX implementations because that was the de-facto operating system in those days (not counting IBM360, Honeywell GCOS, and other mainframe/mini OS-es).
Unix has system calls like write() that are used by library function like printf() for formatted and more comfortable usage. printf() is using write() in a certain fashion, and sometimes we would like to use it in another way, that's why it would be helpful to also be familiar with those read(), write() andopen(). That said, most of the time, printf() will be the more suitable choice for writing ,instead of write().
Also, read this
Functions read, write, ... are more primitive and provide direct reading/writing to OS. fread, fwrite, ... implement a more convenient buffered interface to those primitive functions. However, the convenience costs something. For example asynchronous input/output is not available for those functions. Also there is no equivalent to select. If you need those functionalities, you don't have the choice.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
I'm working on Ubuntu 16.04 and I need to use those functions
int spawnv( mode, path, argv );
int spawnve( mode, path, argv, envp );
int spawnvp( mode, file, argv );
int spawnvpe( mode, file, argv, envp );
I know that they are compiler dependent, so how to find system calls supported by my compiler/system? or how to find my multi-tasking api for processes system calls?
I tried using man spawn + clicking on tab but nothing appears.
The Wikipedia page on Spawn (computing) indicates that the spawn*() functions you reference are from DOS/Windows. They don't have direct analogues in Unix — although they were originally derived from Unix (fork() and exec*()) and adapted to DOS/Windows.
There are no direct analogues to those functions in POSIX. Arguably the nearest approach is posix_spawn() and its multitude of support functions (see the 'SEE ALSO' section on that page for links to the other functions).
I didn't find any similar functions in Linux, even when looking at:
https://man7.org/linux/man-pages/man3
https://man7.org/linux/man-pages/man2
https://linux.die.net/man/2
https://linux.die.net/man/3
Similar functionality can probably be written using fork() (sometimes), exec*() and waitpid() or one of its relatives (sometimes), but it might not be as easy as all that. It depends in part on how exact and complete the emulation functionality has to be.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
Kind of a stupid question but seeing if its possible.
With the f commands you have for example, "w" which would be write to file, create new file if it doesn't exist.
With the O commands its a bit more complex, my research shows its: O_WRONLY|O_TRUNC|O_CREAT
the o commands seems a bit too much to remember oppose to the f command. Is it "good coding" and possible to use W as the flag in an open function
The fopen function is defined in the ISO C standards (C99 7.19.5.3 for example). It is implemented in the C runtime library. As such all compliant C implementations, across all platforms, have to implement it.
The open function is defined in POSIX. It is specific to unix-like platforms.
When you call fopen on a unix-like, POSIX compliant platform, the runtime library inspects the arguments you are supplying and translates them into the corresponding arguments to the POSIX open function.
If you called fopen on another system, such as Windows, the runtime library would be calling a windows specific function to open the file - perhaps OpenFile.
You can't just supply the fopen arguments directly to POSIX open, or to Windows OpenFile for that matter. Those functions don't understand them.
In terms of "good programming" and which of these layers to use: in general, you should avoid directly calling OS system calls (such as the POSIX ones or the windows ones) unless you specifically need to for some reason. The reason is that your program will be more portable if you don't. It will be possible to compile it for any platform which has a compliant C compiler.
On the other hand, if you need some capability or option which is not available in the C Runtime libraries, then you should use the OS system calls.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
On windows, the programmer could do something like: system("ls > outputFile.txt")
Is there a platform independent way to access the command line, or a least a way to determine which platform the program is being executed on (because calls for the same functionality vary quite a bit)?
The system(3) function is standard ANSI C, it's already platform-independent. Any conforming C implementation will allow you to call it to run the system default command line processor/shell application. Of course, the actual programs you can run will vary from system to system (e.g. dir only works on Windows, while ls usually works on Unix-like platforms).
system() itself is a standard C function defined in stdlib.h. The way it interprets its argument, though, is not standard (e.g. ls in UNIX, dir in Windows/DOS, etc.). If you're really asking whether there's a platform-independent way to list the files in a directory, the answer is (unfortunately) no. Some libraries do provide portable (to some degree) implementations, most notably Boost: How can I get the list of files in a directory using C or C++?
This question already has answers here:
How to create a lightweight C code sandbox?
(13 answers)
Closed 9 years ago.
I'm developing a platform similar to hackerrank.com where someone can submit C code, and then that code will be compiled, and run on my server, but I want to limit the C instruction set that a person will be able to execute on my server.
For example: limit the instruction set to I/O only.
My first approach was to parse the code and look for malicious code, but that is pretty naive because it can be easily overriden (shell code, obfuscation, etc..)
My second approach (the one I think it could work) is to remove all the "unnecessary" headers, and just leave stdio.h, math.h, stdlib.h, etc... just to name a few.
But then I thought that it might be possible to limit from gcc the instruction set of C, but after reading the man entry for gcc I couldn't find anything close to what I need, so I wonder if that's even possible.
If that's not possible, what could be a safe way to solve this problem? Other than getting rid of unnecessary libraries.
Thanks!
You could limit system calls using systrace, which is available on OpenBSD. I'm sure there's an equivalent for linux and other operating systems. This would allow you to restrict syscalls to file io only and not things like sockets and forking.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
#define __HAVE_ARCH_STRCPY
What's the meaning of __HAVE_ARCH ? I'm not a native speaker and I fail to find the meaning of it by google...(maybe this question is quite silly)
By defining the __HAVE_ARCH_XXXX pre-processor tokens, it allows other locations in the OS kernel to test if the current hardware platform supports the strcpy, memset, etc. functionality. You'll notice that on some platforms, this token is defined, and then a basic implementation of these functions are defined as inline functions along with the token, since on those platforms, the functionality is not provided by some other kernel library or kernel code module. On other platforms, the functions are defined in some other code module, and may be simply declared as extern just after the pre-processor token.
Keep in mind that the kernel itself in Linux does not have access to the standard libc library, so these functions have to be defined separately from what you would typically use in a user-land application that is linked against libc. Thus it's important to define what standard functions are present, and which ones are not, as it may vary from platform-to-platform.
"This architecture has strcpy()".