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.
Related
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 2 years ago.
Improve this question
ISO:IEC 9899 standardizes the prototypes of the functions of the C standard library and describes their behavior. It specifies the identifier, the return type and the parameter(s) with its matching type(s) of a certain C standard function.
But why it does not specify the definitions - (the core how the specific functions actually do work)?
Why can a C standard library function X differ in its actual source code between f.e. the gcc compiler suite on Linux (GNU C Library), clang suite on macOS and the core system dynamic libraries for Microsoft Visual C++ on Windows? Why is it dependent upon the implementation, the operation system and the relative compiler design?
Edit:
I know the question seems bad for the most of yours at the first sight but it has definitely a right to get answered, since I don´t know the reason for that yet.
I do not suggest that the ISO shall standardize the definitions because the question was closed as opinion-based - don´t get me wrong. I just ask why are things that way and want to learn from your knowledge and experience.
Take strlen for example. If the ISO C standard standardized the definition of this function, it would probably look like this:
size_t strlen(char *s)
{
size_t l = 0;
while(s[l]) l++;
return l;
}
This is highly inefficient. The GNU C library has implementations written in assembly and C that are very fast, but aren't portable.
Some functions may be impossible to standardize. For example, how would it define putchar, vfprintf, and fwrite? What about assembly functions like longjmp? Or "macros" like setjmp?
Other definitions may be exploited. For example, if the Standard C committee standardizes memcpy, two things would happen:
people can abuse the copy order, and
existing implementations would be invalidated.
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 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.
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
I'm starting a pet project, aimed at portability. It's a simple platform game and i'm planning to compile this to many different platforms with different toolchains. The video/input/system stuff is already abstracted by having multiple video drivers, which i include based on ifdef's around my code. Each platform makefile has a define of the platform (DC, NDS, PSP, etc.) and then i include the proper video drivers, which are C files with various functions called around my code.
However, i'm not sure about other caveats of portable applications in C. Should i redefine stuff from the stdlib? u8, u16, u32 and s8, s16, s32, etc? What knowledge can you share with me for this project?
A portable program is a program that:
only uses the features of the language and library defined in the C Standard
does not invoke undefined behavior
does not depend on unspecified or implementation defined behavior.
For a list of undefined, unspecified and implementation defined behaviors, you can go the C Standard C11, Appendix J (Portability issues).
Writing in C is more or less portable as long as you make no suppositions about the sizes of your types and the pointers you use to access them. I personally prefer using the types defined in stdint.h (http://pubs.opengroup.org/onlinepubs/7999959899/basedefs/stdint.h.html) - this defines like uint8_t, uint16_t ... - but feel free to research more alternatives, such as types.h (from POSIX Standard: 2.6 Primitive System Data Types) which defines them as u_int8_t etc ...
Possibly, you will end up at the end defining your own types based on what you managed to mangle together from the various sources found on the net ... such as: game_int_16 ,game_int_32 ...
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++?