I tried including string.h and stdlib.h, but still get undefined reference compile errors.
This leads me to conclude that it is in a different library that I didn't include. Where is it?
I am using gcc compiler - the code is written in Windows, but is going to be compiled and run on a unix server.
strcat_s can be found in string.h as of C 2011. Generally speaking, only microsoft has implemented these alternative functions.
There's an implementation in slibc.
It is present in string.h on windows platform
You can also refer this cppreference
Defined in header <string.h>
You can better use strcat if you are working on UNIX platform.
It seems it is part of C11 standard:
http://en.cppreference.com/w/c/string/byte/strcat
https://www.securecoding.cert.org/confluence/display/c/API02-C.+Functions+that+read+or+write+to+or+from+an+array+should+take+an+argument+to+specify+the+source+or+target+size
Honestly, I am not very well-versed with when it comes to standards and I can very well be wrong >.<
Related
Is there any way to access thread.h file .
I am not able to find thread.h header in windows since threading is related to OS.
I tried using pthread.h an external library , but was never able to find thread.h which according to my professor works in solaris.
This is an excellent example where tagging a question with "C" and "C++" is highly confusing because the answers are entirely different.
If you are coding in C++11 or later, then you should
#include <thread>
and use the std::thread class. You'll be fine.
If you are coding in C11 or later, then you should
#include <threads.h>
However, you may have to wait until your implementation supports it. § 7.26.1 ¶ 2 of the C11 standard says:
Implementations that define the macro __STDC_NO_THREADS__ need not provide this header nor support any of its facilities.
You can check with an #ifdef whether your implementation defines it. At least my GCC does.
For the time being, if you cannot switch to C++, use a third-party threading library like pthreads.
thread.h isn't well defined in the context of c++ standards. If you have a c++11 compliant toolchain, you need to
#include <thread>
as stated in the reference documentation.
Pre standard toolchains probably need to have the standard specified explicitly using the -std=c++0x or -std=c++11 compiler flags.
As you changed your focus to c, including c++ headers won't work. You may try pthread.h.
I've recently migrated from Windows 7 to Linux (Ubuntu 14.04) and want to compile a C program that I made. The program worked perfectly under Codeblocks 12.11 using GNU GCC compiler's basic settings. When compiling under linux under Codeblocks 13.12 using GNU GCC compiler's basic settings, I get the following error messages:
undefined reference to __mingw_vprintf
undefined reference to __chstk.ms
undefined reference to _fopen
... and so on with fscanf, malloc, etc...
I'm new to Linux and I am not used to C coding, or even programming in general. Does someone have an idea about what's going on?
you have three separate problem going on here.
(1) for _fopen, Microsoft has a nasty habit of renaming all the POSIX functions so they start with an underscore, while your Linux distribution is looking for the standard POSIX name, i.e. fopen. Welcome to the wonderfully frustrating world of cross-platform development :). On solution would be to add something along these lines:
#ifdef __WIN32
#define fopen _fopen
#endif
This in effect says, if compiling on a windows machine (which typically has __WIN32 defined as a preprocessor define; and if it is not you can always make sure that it is) replace every occurrence of fopen with _fopen. The preprocessor will do this for you.
(2) for __mingw_vprintf, I've never seen this function but from the name I would surmise that it is an implementation of vprintf specific to mingw. I personally would rewrite my code to stick with the standard C function vprintf. You can read the manual page for vprintf here; and the MSDN information can be found here. Again notice that many of the Microsoft provide functions have an underscore prepended to the name. You can do something like what you did in case (1) above.
N.B. Actually if I were to rewrite the program I would use C++ IO-streams, but I am sticking to a pure C answers.
(3) for __chstk.ms, again I've never seen this function. My suspicion is that it is something inserted into your code to perform stack checking to help prevent stack-based exploits. To the best of my knowledge there is no way you are going to get that to work on a Linux machine.
I noticed that the difference between linux and windows.
strcmpi is in windows C standard libary implementation but it is not in GNU's C standard libary implementation.
Is the function strcmpi in the C standard libary defined by ISO?
How can I get the standard file?
Thank you.
The POSIX Standard (aka, UNIX) has strcasecmp() but it's not part of C99 / ISO-C.
Note: If you compare the above reference with e.g. the one for strcmp() you'll note that the latter explicitly references ISO-C, while the former does not. An useful feature of the OpenGroup references.
Edit: Since the locale-dependency was mentioned as a complication, see the above reference for strcasecmp_l() which allows explicitly specifying the locale to be used for the conversion. Windows has _strcmpi_l() for the purpose, again keeping with its own naming conventions.
Nope, it's a non-standard extension. Unix-like systems commonly have a strcasecmp which performs the same task as MS's strcmpi.
Nope, a quick CTRL+F in the standard returns nothing for strcmpi. This means that it is a non-standard extension (of which both Windows and GNU have a lot).
I use dev c++ for my c projects,because it's simple for me.I installed it with the mingw extension.Well,I included stdlib.h and made a call to mrand which according to manpages belongs to that header but I got a linker error.I looked in mingw's headers and found no declaration for mrand although the glibc has one in stdlib.Am I missing something?I thought mingw and gcc were the same.If they are different I suppose that there isn't a way to get gcc's full power.Right?Thank you.
mrand is not part of the standard C library, nor is it present in standard Linux manpages. Whatever compiler you previously used may have had it as a proprietary extension, but since you haven't mentioned which (it's not GCC or MSVC, at least), I can't tell what mrand is supposed to do, and so it's hard to suggest an alternative function to use.
Note that glibc does offer a mrand48(). Since this is a POSIX function, not a standard C function, it may or may not be present in other C libraries - but note that this is a function of the C library (glibc), not the compiler (gcc/mingw).
Having just seen What does the following macro do? I gotta ask my own question: why do so many applications' headers define offsetof themselves? Is there some reason why <stddef.h> is not to be relied upon?
I don't think it's that they distrust the standard offsetof -- at least from what I've seen, it's usually that they're just unaware of it.
Is there some reason why is not to be relied upon?
I know one of the reasons. GCC produces a warning when standard offsetof() is used on fields of C++ classes. That leads some people to roll out their own version which doesn't trigger the warning.
Or maybe it's legacy code from a C compiler that wasn't ANSI compliant and didn't have offsetof?