I got following warning while compiling on x86_64 gcc:
warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but
argument 2 has type ‘u64’
Both unsigned long long and u64 are 64-bit unsigned integer, aren't they?
So what is exactly the difference that gcc considers about them?
In short llu can be 64 bit but this is not a must. It all depends on the machine, compiler etc. You should consider using PRIu64 in your case.
Your question has already been answered in detail here: Link
Related
Couldn't find any documentation on -Wno-four-char-constants, however I suspect that it is similar to -Wno-multichar. Am I correct?
They're related but not the same thing.
Compiling with the -Wall --pedantic flags, the assignment:
int i = 'abc';
produces:
warning: multi-character character constant [-Wmultichar]
with both GCC and CLANG, while:
int i = 'abcd';
produces:
GCC warning: multi-character character constant [-Wmultichar]
CLANG warning: multi-character character constant [-Wfour-char-constants]
The standard (C99 standard with corrigenda TC1, TC2 and TC3 included, subsection 6.4.4.4 - character constants) states that:
The value of an integer character constant containing more than one character (e.g., 'ab'), [...] is implementation-defined.
A multi-char always resolves to an int but, since the order in which the characters are packed into one int is not specified, portable use of multi-character constants is difficult (the exact value is implementation-dependent).
Also compilers differ in how they handle incomplete multi-chars (such as 'abc').
Some compilers pad on the left, some on the right, regardless of endian-ness (some compilers may not pad at all).
Someone who can accept the portability problems of a complete multi-char may anyway want a warning for an incomplete one (-Wmultichar -Wno-four-char-constants).
I discovered few days ago Compound literals in the answer How do I use setsockopt(SO_REUSEADDR)?
So I tried to compile simple code :
#include <stdio.h>
int main()
{
int * ptr = &(int) {3};
printf("%d\n", *ptr);
return 0;
}
Using gcc 4.9.1, it build and works as expected, it print "3" and valgrind doesnot report memory corruption.
However using g++ 4.9.1, it does not build :
$ g++ main.c
main.c: In function ‘int main()’:
main.c:4:23: error: taking address of temporary [-fpermissive]
int * ptr = &(int) {3};
^
Is there is a way (like an g++ option) to support Compound literal ?
In C language compound literals are lvalues. It is perfectly legal to take address of a compound literal in C. In C a local compound literal lives to the end of its enclosing block.
Meanwhile, GCC brings over compound literals to C++ (as a non-standard extension) with a number of significant changes. They are brought over as temporary objects. It is illegal to take address of a temporary object in C++. The lifetime of compound literals in C++ is also consistent with lifetime of temporaries - they live to the end of the expression.
AFAIK, there's no way to make GCC's C++ compound literals to behave as their C counterparts.
I have installed MPICH (ver 3.0.4) on my linux machine (CentOS 6.4) for doing some parallel computation. I tried to compile "pmandel.c" (which comes with MPICH installation package as an example) to test my MPICH installation with this command :
mpicc pmandel.c -o pmandel.out
but it returns these errors:
pmandel.c: In function ‘main’:
pmandel.c:279: warning: passing argument 2 of ‘bind’ from incompatible pointer type
/usr/include/sys/socket.h:115: note: expected ‘const struct sockaddr *’ but argument is of type ‘struct sockaddr_in *’
pmandel.c:282: warning: passing argument 2 of ‘bind’ from incompatible pointer type
/usr/include/sys/socket.h:115: note: expected ‘const struct sockaddr *’ but argument is of type ‘struct sockaddr_in *’
pmandel.c:296: warning: passing argument 2 of ‘getsockname’ from incompatible pointer type
/usr/include/sys/socket.h:119: note: expected ‘struct sockaddr * __restrict__’ but argument is of type ‘struct sockaddr_in *’
/tmp/cclNv8nA.o: In function `exponential_complex':
pmandel.c:(.text+0x2fc2): undefined reference to `exp'
pmandel.c:(.text+0x2fd1): undefined reference to `cos'
pmandel.c:(.text+0x2fe5): undefined reference to `sin'
/tmp/cclNv8nA.o: In function `absolute_complex':
pmandel.c:(.text+0x3330): undefined reference to `sqrt'
collect2: ld returned 1 exit status
and no output is made. I also tried with "mpic++", "mpiCC", mpicxx" ... but all to no avail.
what should I do to correct this?
#Spiros is correct that you need to add -lm to your mpicc. It matters where in the command you specify it, too.
"It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified. Thus, ‘foo.o -lz bar.o’ searches library ‘z’ after file foo.o but before bar.o. If bar.o refers to functions in ‘z’, those functions may not be loaded."
see http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html.
It comes after pmandel.out.
mpicc pmandel.c -o pmandel.out -lm
Alternatively, you can use the Makefile included in the mpich examples directory and just type
make pmandel
I'm trying to build Derelict2 on Lion as per the included installation instructions. When I run the command make -fmac.mak DC=dmd the following libraries build fine:
DerelictAllegro
DerelictFMOD
DerelictFT
DerelictGL
DerelictIL
DerelictODE
DerelictOgg
DerelictPA
Unfortunately once the script gets up to DerelictSDL it spits out the following:
make -C DerelictSDL all PLATFORM=mac
dmd -release -O -inline -I../DerelictUtil -c derelict/sdl/sdl.d derelict/sdl/sdlfuncs.d derelict/sdl/sdltypes.d -Hd../import/derelict/sdl
dmd -release -O -inline -I../DerelictUtil -c derelict/sdl/macinit/CoreFoundation.d derelict/sdl/macinit/DerelictSDLMacLoader.d derelict/sdl/macinit/ID.d derelict/sdl/macinit/MacTypes.d derelict/sdl/macinit/NSApplication.d derelict/sdl/macinit/NSArray.d derelict/sdl/macinit/NSAutoreleasePool.d derelict/sdl/macinit/NSDictionary.d derelict/sdl/macinit/NSEnumerator.d derelict/sdl/macinit/NSEvent.d derelict/sdl/macinit/NSGeometry.d derelict/sdl/macinit/NSMenu.d derelict/sdl/macinit/NSMenuItem.d derelict/sdl/macinit/NSNotification.d derelict/sdl/macinit/NSObject.d derelict/sdl/macinit/NSProcessInfo.d derelict/sdl/macinit/NSString.d derelict/sdl/macinit/NSZone.d derelict/sdl/macinit/runtime.d derelict/sdl/macinit/SDLMain.d derelict/sdl/macinit/selectors.d derelict/sdl/macinit/string.d -Hd../import/derelict/sdl/macinit
derelict/sdl/macinit/NSString.d(134): Error: cannot implicitly convert expression (this.length()) of type ulong to uint
derelict/sdl/macinit/NSString.d(135): Error: cannot implicitly convert expression (str.length()) of type ulong to uint
derelict/sdl/macinit/NSString.d(140): Error: cannot implicitly convert expression (cast(ulong)(selfLen + aStringLen) - aRange.length) of type ulong to uint
make[1]: *** [dmd_mac_build_sdl] Error 1
make: *** [DerelictSDL_ALL] Error 2
The latest version of Derelict is Derelict3, which is on GitHub.
As for your error, it looks like you are compiling for 64-bit, which apparently hasn't been taken into consideration in Derelict2.
You'll just need to fix the source code. The correct way to do this would be to change those instances to use size_t instead of uint, but it might be easier just to cast(size_t) those expressions until the errors go away :-) It's unlikely that the lengths will ever be above 4 billion, so you should be fine until you switch over to Derelict3.
Try to compile in 32 bit mode. I believe it is the -m32 option for dmd and gdc/gdmd
I have some C++0x code. I was able to reproduce it below. The code below works fine without -std=c++0x however i need it for my real code.
How do i include strdup in C++0x? with gcc 4.5.2
note i am using mingw. i tried including cstdlib, cstring, string.h and tried using std::. No luck.
>g++ -std=c++0x a.cpp
a.cpp: In function 'int main()':
a.cpp:4:11: error: 'strdup' was not declared in this scope
code:
#include <string.h>
int main()
{
strdup("");
return 0;
}
-std=gnu++0x (instead of -std=c++0x) does the trick for me; -D_GNU_SOURCE didn't work (I tried with a cross-compiler, but perhaps it works with other kinds of g++).
It appears that the default (no -std=... passed) is "GNU C++" and not "strict standard C++", so the flag for "don't change anything except for upgrading to C++11" is -std=gnu++0x, not -std=c++0x; the latter means "upgrade to C++11 and be stricter than by default".
strdup may not be included in the library you are linking against (you mentioned mingw). I'm not sure if it's in c++0x or not; I know it's not in earlier versions of C/C++ standards.
It's a very simple function, and you could just include it in your program (though it's not legal to call it simply "strdup" since all names beginning with "str" and a lowercase letter are reserved for implementation extensions.)
char *my_strdup(const char *str) {
size_t len = strlen(str);
char *x = (char *)malloc(len+1); /* 1 for the null terminator */
if(!x) return NULL; /* malloc could not allocate memory */
memcpy(x,str,len+1); /* copy the string into the new buffer */
return x;
}
This page explains that strdup is conforming, among others, to the POSIX and BSD standards, and that GNU extensions implement it. Maybe if you compile your code with "-D_GNU_SOURCE" it works?
EDIT: just to expand a bit, you probably do not need anything else than including cstring on a POSIX system. But you are using GCC on Windows, which is not POSIX, so you need the extra definition to enable strdup.
add this preprocessor "_CRT_NONSTDC_NO_DEPRECATE" to Project Properties->C/C++ Build->GCC C++ Compiler->Preprocessor->Tool Settings
Don't forget to check Preprocessor Only(-E)
This worked for me on windows mingw32.