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()".
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
I'm building a portable C library that needs to interact with a user-defined peripheral.
Here's an example,
My library needs to use a user-defined putc() and a getc().
To my understanding, there's two way to do this cleanly:
Using an "install" function that requires user to define interface with function pointers
// Inside mylib.h
typedef int (*mylib_port_putc)(char c);
typedef int (*mylib_port_getc)(char *c);
void mylib_install_port(mylib_port_putc, mylib_port_getc);
Using the extern keyword to let the user decide where to define the interfaces.
// Inside mylib.h
extern int mylib_port_putc(char c);
extern int mylib_port_getc(char *c);
What's the best way to do this?
I understand that "best" is difficult to define, but your opinion would be greatly appreciated.
EDIT:
I disagree with the StackOverflow maintainers to flag this question as inappropriate. I don't think this website should be limited to "how do I do X?" questions. I understand that asking for opinions will probably not generate a clear answer, but, to me, this is what mentorship looks like.
When you're starting, there's a lot of value in studying knowledgeable people debating tradeoffs.
Sorry for the rent. I know your job is hard. Happy holidays.
I think that the only correct way is the first -
you provide a library initialize(...) function for registering user callback functions - port_putc, port_getc, maybe also callbacks for you library logging, etc.
Such an approach is flexible, and very common.
In the second case, you require the library users to define 2 functions with predefined names in their code.
What happens if he didn't?
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 4 years ago.
Improve this question
There are two ways to link a shared library .
one named implicit dynamic linking and one named explicit dynamic linking.
I have googled some doc not found docs tells the difference on efficiency of the two .
Take a linux .so file as example . my doubt is : the implicit linking compare with the explicit way , will the explicit way cause more IO or cpu or memory somehow ?
Wondering which way is more effective and why ?
thanks a lot !
From what I understand, implicit dynamic linking is the fact of saying that your program needs the library in order to run, by adding the library in the dependency section of your program. If the library isn't found at the start of the program, the program simply won't be executed.
Explicit dynamic linking is using a function like "LoadLibrary" (windows) or "dlopen" (Linux) in order to load a library at runtime. It's exactly what a plugin is, and how you can code it.
Now, doing an explicit dynamic linking is going to add work and complexity, and I don't see any reason for it to be more efficient than an implicit dynamic linking. You use explicit dynamic linking only when you cannot do otherwise, like loading a library depending on some runtime value.
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++?