I have a simple program to test basename() method:
#include <stdio.h>
#include <string.h>
//#include <libgen.h>
int main (int argc , char **argv)
{
char *a = strdup("test();");
printf("%s", basename(a));
return 0;
}
clang complains but it compiles anyway.
test.c:7:18: warning: implicit declaration of function 'basename' is invalid in C99 [-Wimplicit-function-declaration]
printf("%p", basename(a));
^
test.c:7:18: warning: format specifies type 'void *' but the argument has type 'int' [-Wformat]
printf("%p", basename(a));
And it results in segfault. But if I added libgen.h header, it works normally.
I've checked the binary with otool, it linked against the same dylib, nothing else. Why does the first one crash?
I've checked the answer here already, it uses a static buffer but I use the result from strdup(), so it's a different question.
Related
When trying to parse a number too big to fit a long, strtol() returns 0 instead of LONG_MAX (stdio.h). If I read the POSIX spec correctly, it should be LONG_MAX. There is a different between stdio.h and stdlib.h
#include "stdio.h"
int main(void){
printf("%ld\n", strtol("99999999999999999999999"));
return 0;
} # 0
#include "stdio.h"
//#include "stdlib.h"
int main(void){
char *end[500];
printf("%ld\n", strtol("99999999999999999999999", end, 10));
return 0;
} # 9223372036854775807
strtol is declared in header <stdlib.h> as
long strtol( const char *restrict str, char **restrict str_end, int base );
// ^^^^^^^^ ^^^^^^^^ since C99
In the first posted snippet, <stdlib.h> is not included and the function is called with one single argument, so that, if compiled with -Wall -Wextra -std=gnu11, gcc produces the following explanatory warnings before outputting 0:
prog.c: In function 'main':
prog.c:5:21: warning: implicit declaration of function 'strtol' [-Wimplicit-function-declaration]
printf("%ld\n", strtol("99999999999999999999999"));
^~~~~~
prog.c:5:15: warning: format '%ld' expects argument of type 'long int', but argument 2 has type 'int' [-Wformat=]
printf("%ld\n", strtol("99999999999999999999999"));
~~^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
%d
Which means that the library function is not called at all and an implicitly declared function with the same name is called, an int with value 0 is returned and printed (with the wrong format specifier, which is itself undefined behavior).
Note that the same code fails to compile with clang, which reports the following:
prog.c:4:21: warning: implicitly declaring library function 'strtol' with type 'long (const char *, char **, int)' [-Wimplicit-function-declaration]
printf("%ld\n", strtol("99999999999999999999999"));
^
prog.c:4:21: note: include the header <stdlib.h> or explicitly provide a declaration for 'strtol'
prog.c:4:53: error: too few arguments to function call, expected 3, have 1
printf("%ld\n", strtol("99999999999999999999999"));
~~~~~~ ^
1 warning and 1 error generated.
In the second snippet, strtol is called with the right number of arguments, but, as posted (with the #include commented out), has the same missing header problem. To produce the expected output, LONG_MAX, header stdlib.h has to be included.
I have a piece of code in my .y file as follows
void yyerror(s) char *s; {
fputs(s, stderr);
putc('\n', stderr);
}
The function prototype declaration is in another file as follows
void yyerror (char const *s);
I tried to compile the code on both Linux and mac. On Linux, the compiler generates the following error message
error: argument ‘s’ doesn’t match prototype
void yyerror(s) char *s; {
^
On mac, the compiler generates the following warning message
warning: promoted type 'char *' of K&R function parameter is not compatible with the parameter type 'const char *' declared in a previous prototype [-Wknr-promoted-parameter]
void yyerror(s) char *s; {
^
My questions are:
Why clang only generates warning while cc generates an error.
Both compilers complain about 's' in "char *s". Why they ignore the 's' in () but consider the second 's' as the argument?
I'm trying to use thrust::transform to operate on vectors of type thrust:complex<float> without success. The following example blows up during compilation with several pages of errors.
#include <cuda.h>
#include <cuda_runtime.h>
#include <cufft.h>
#include <thrust/device_vector.h>
#include <thrust/host_vector.h>
#include <thrust/transform.h>
#include <thrust/complex.h>
int main(int argc, char *argv[]) {
thrust::device_vector< thrust::complex<float> > d_vec1(4);
thrust::device_vector<float> d_vec2(4);
thrust::fill(d_vec1.begin(), d_vec1.end(), thrust::complex<float>(1,1));
thrust::transform(d_vec1.begin(), d_vec1.end(), d_vec2.begin(), thrust::abs< thrust::complex<float> >() );
}
I'm using CUDA 8.0 on Ubuntu Xenial and compiling with clang 3.8.0-2ubuntu4 using nvcc --std=c++11 main.cpp -o main.
Main errors appear to be:
main.cpp: In function ‘int main(int, char**)’:
main.cpp:17:105: error: no matching function for call to ‘abs()’
gin(), d_vec1.end(), d_vec2.begin(), thrust::abs< thrust::complex<float> >() );
and
/usr/local/cuda-8.0/bin/../targets/x86_64-linux/include/thrust/detail/complex/arithmetic.h:143:20: note: template argument deduction/substitution failed:
main.cpp:17:105: note: candidate expects 1 argument, 0 provided
gin(), d_vec1.end(), d_vec2.begin(), thrust::abs< thrust::complex<float> >() );
^
No problem working on real floats, but no such with complex ones. I'm thinking there's a type error that I'm missing, but I'm very much still on the steep part of the learning curve with Thrust & templates.
The error message is quite descriptive:
thrust::abs<thrust::complex<...>> is a function which expects exactly one parameter, see thrust/detail/complex/arithmetic.h#L143:
template <typename ValueType>
__host__ __device__
inline ValueType abs(const complex<ValueType>& z){
return hypot(z.real(),z.imag());
}
For your use case, you need to wrap that function by a functor:
struct complex_abs_functor
{
template <typename ValueType>
__host__ __device__
ValueType operator()(const thrust::complex<ValueType>& z)
{
return thrust::abs(z);
}
};
Finally, employ that functor here:
thrust::transform(d_vec1.begin(),
d_vec1.end(),
d_vec2.begin(),
complex_abs_functor());
Here is the minimal C program to reproduce:
#include <alsa/asoundlib.h>
#include <sys/time.h>
int main( void )
{
}
This will compile with gcc -c -o timealsa.o timealsa.c, but if you include the -std=c99 switch, you get a redefinition error:
In file included from /usr/include/sys/time.h:28:0,
from timealsa.c:3:
/usr/include/bits/time.h:30:8: error: redefinition of ‘struct timeval’
struct timeval
^
In file included from /usr/include/alsa/asoundlib.h:49:0,
from timealsa.c:2:
/usr/include/alsa/global.h:138:8: note: originally defined here
struct timeval {
^
How can I resolve this conflict while still using -std=c99?
Since your question suggests you are using GLIBC's time.h there is a way to avoid this by telling it not to define timeval. Include asoundlib.h first then define _STRUCT_TIMEVAL. The one defined in asoundlib.h will be the one that gets used.
#include <alsa/asoundlib.h>
#ifndef _STRUCT_TIMEVAL
# define _STRUCT_TIMEVAL
#endif
#include <sys/time.h>
int main( void )
{
}
With C99 and later you can't have duplicate definitions of the same struct. The problem is that alsa/asoundlib.h includes alsa/global.h which contains this code:
/* for timeval and timespec */
#include <time.h>
...
#ifdef __GLIBC__
#if !defined(_POSIX_C_SOURCE) && !defined(_POSIX_SOURCE)
struct timeval {
time_t tv_sec; /* seconds */
long tv_usec; /* microseconds */
};
struct timespec {
time_t tv_sec; /* seconds */
long tv_nsec; /* nanoseconds */
};
#endif
#endif
So the Michael Petch's solution won't work - by the time you've included alsa/asoundlib.h it is already too late. The proper solution is to define _POSIX_C_SOURCE (_POSIX_SOURCE is obsolete). There's more information about these macros here and here.
For example you could try -D_POSIX_C_SOURCE=200809L. However, if you do that you'll get errors like this:
/usr/include/arm-linux-gnueabihf/sys/time.h:110:20: error: field ‘it_interval’ has incomplete type
struct timeval it_interval;
^
/usr/include/arm-linux-gnueabihf/sys/time.h:112:20: error: field ‘it_value’ has incomplete type
struct timeval it_value;
^
/usr/include/arm-linux-gnueabihf/sys/time.h:138:61: error: array type has incomplete element type
extern int utimes (const char *__file, const struct timeval __tvp[2])
^
This is all a big mess of old C code and macro madness. The only way I got it to work was to give up and use -std=gnu11.
I have the following c++ source test in MinGW in winx , g++ version is 4.8.1 :
compiled : g++ -std=c++11 int64test.cpp -o int64test.exe
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <sched.h>
#include <errno.h>
#include <string.h>
#include <errno.h>
#include <atomic>
#include <iostream>
#include <cstdint>
using namespace std ;
int main(int argc, const char *argv[])
{
atomic<unsigned int> uintlocal1(1000) ;
unsigned int uint1,uint2,uint3 ;
uint1 = uintlocal1.fetch_add(1) ;
uint2 = uintlocal1.fetch_add(1) ;
uint3 = uintlocal1.fetch_add(1) ;
printf("(%d)(%d)(%d)(%d)\n",uint1,uint2,uint3,unsigned(uintlocal1)) ;
atomic<uint64_t> uint64local1(1000) ;
uint64_t u1,u2,u3 ;
u1 = uint64local1.fetch_add(1) ;
u2 = uint64local1.fetch_add(1) ;
u3 = uint64local1.fetch_add(1) ;
printf("(%d)(%d)(%d)(%d)\n",u1,u2,u3,unsigned(uint64local1)) ;
}
The answer is :
(1000)(1001)(1002)(1003)
(1000)(0)(1001)(0)
Obviously , the atomic uint64_t is wrong , while atomic int is right !!
But I don't know what cause this problem , what should I modify so that I
can use atomic correctly ...thanks !!
You are using incorrect formats for the line printing uint64_t data. When I compile your code my compiler produces the following warnings:
main.cpp:18:33: warning: format specifies type 'int' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Wformat]
printf("(%d)(%d)(%d)(%d)\n",u1,u2,u3,unsigned(uint64local1)) ;
~~ ^~
%llu
main.cpp:18:36: warning: format specifies type 'int' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Wformat]
printf("(%d)(%d)(%d)(%d)\n",u1,u2,u3,unsigned(uint64local1)) ;
~~ ^~
%llu
main.cpp:18:39: warning: format specifies type 'int' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Wformat]
printf("(%d)(%d)(%d)(%d)\n",u1,u2,u3,unsigned(uint64local1)) ;
~~ ^~
%llu
Note: You can enable a similar format checking warning in GCC 4.8.1 using the flag -Wformat, or better yet, -Wall.
On my platform the types int and unsigned long long are not layout compatible and so when printf tries to access a vararg specified by %d when the actual passed argument is uint64_t the result will be undefined behavior.
The normal formatters for printf such as %d and %llu are used for built in types such as int or unsigned long long. The types in stdint.h are not built in and may correspond to different built-in types on different platforms, requiring different formatters on each platform.
For example int64_t might be the same as int on one platform and the same as long long on a different platform. Since to use int in printf you use the format specifier %d and to use long long you use the format specifier %lld, you cannot write portable code using stdint types and the normal format specifiers.
Instead, the header inttypes.h is provided with macros that contain the correct format specifiers. The macro for uint64_t is PRIu64. This macro will be defined to be whatever the correct format specifier is on your platform. Use it like this:
printf("(%" PRIu64 ")(%" PRIu64 ")(%" PRIu64 ")(%u)\n",u1,u2,u3,unsigned(uint64local1));
Make sure you get the spaces put in between the macro and the quoted string fragments, otherwise in C++11 the macros will not work correctly.
Here's a useful reference on the normal formatters: http://en.cppreference.com/w/cpp/io/c/fprintf
Here's a reference for the stdint.h types and formatters: http://en.cppreference.com/w/cpp/types/integer
Note: Using incorrect format specifiers with printf an easy mistake to make and leads to undefined behavior. One of the advantages of the iostream library is that this sort of mistake is impossible.