c99

I keep getting implicit declaration of function 'execle' is invalid in C99 when compiling the code below. What am I missing? #include <stdio.h> #include <stdlib.h> char *my_env[] = {"JUICE=PEACH and apple", NULL}; int main (int argc, char *argv[]) { execle ("diner_info", "diner_info", "4", NULL, my_env); printf ("Diners: %s\n", argv[1]); printf ("Juice: %s\n", getenv("JUICE")); return 0; } Sourav Ghosh In C99 , the implicit declaration of a function is not allowed. That means, the compiler should be aware of the function signature before it encounters a call to that function. This can be

I have a utility library of C99 code used by C++11 application code. A few inline functions are declared in the C99 style with code explicitly generated in the translation unit like: // buffer.h inline bool has_remaining(void* obj) { ... } // buffer.c extern inline bool has_remaining(void * obj); However, when I try to use has_remaining in the C++ application, I get errors about multiple definitions at link time. It seems that g++ is instantiating the inline code that already exists in the library, despite the extern "C" header guards specifier. Is there a way to coerce g++ into working with

I have a question about literals in C. int a; //a is an integer that is assigned an integer literal 414 a = 414; float b; //b is a float that is assigned a float literal of 3.14 b = 3.14; struct point { int x,y; }; struct point b; //{5,6} is a compound literal that is assigned to a struture. b = {5,6}; //doesn't work. b = (struct point){5,6}; //works. That doesn't seem to work without a typecast? What is the reason for this? (struct point){5,6} as a whole is a compound literal. C11 §6.5.2.5 Compound literals A postfix expression that consists of a parenthesized type name followed by a brace

I came across an article which mentioned that the result of !0 is compiler dependent. The result can be either 1 or FF or FFFF and so on. As for C99 standard 6.5.3.3 Unary arithmetic operators, The result of the logical negation operator ! is 0 if the value of its operand compares unequal to 0, 1 if the value of its operand compares equal to 0. The result has type int. The expression !E is equivalent to (0==E). Is it really compiler dependent? You seem to have answered you own question already, quoting from the standard where it specifies that the result must be 0 or 1. As such, about all I

I'm fairly new to C but writing a small multithreaded application. I want to introduce a delay to a thread. I'd been using 'usleep' and the behavior is what I desire - but it generates warnings in C99. implicit declaration of function ‘usleep’ It's only a warning, but it bothers me. I've Googled for an answer but all I could find was a while-loop / timer approach that seemed like it would be CPU intensive. EDIT: My includes are: #include <stdio.h> #include <stdlib.h> #include <pthread.h> #include <unistd.h> #include <time.h> And I'm invoking the compiler with: c99 program.c -Wall -pedantic -W

I read in the c99 Standard: -remove implicit function declaration, -remove implicit int. But when I try to compile this code with gcc compiler in c99 mode using -pedantic main(void){ f(3); return 0; } int f(int a){ .... } I expect 2 errors, but I just receive 2 warnings: -warning: return type defaults to ‘int’ -warning: implicit declaration of function ‘f’. Shouldn't them be errors in c99? http://gcc.gnu.org/c99status.html In both situations there's written "done". Thanks. The C standard requires a diagnostic for any translation unit containing a violation of a syntax rule or constraint. It

When there is a common set of global data that needs to be shared among several threaded processes, I typically have used a thread token to protect the shared resource: Edit - 7/22/15 (to incorporate atomics as a viable option, per Jens comments) My [First] question is , in C, if I write my routines in such a way as to guarantee each thread accesses one, and only one element of an array: Is there any reason to think that asynchronous and simultaneous access to different indices of the same unprotected array (as shown in diagram) would be a problem? Second question: Given that an object that