Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Closed 9 years ago.
Improve this question
I used Microsoft Visual Studio to write a C code in C++ project and It's working fine there when I convert the file extension from my.cpp to my.c and tried to run in via TurboC++ 3.0 then it gives me number of errors like "Constant Expression Required" and "Declaration is not allowed here".
I tried to run my code online compiler but its not giving me these error there.
Can anyone help me with this ?
I hope it's due to C99 mode but not confirmed.
TurboC++ 3.0 Supports C99 or not ?
Note: I can't share my code directly here due to project research work , If anyone want to have a look at my code I can send you via private message , Sorty for that
The error: Declaration Not allowed here is due to the mixed type declaration of variables and the error: Constant Expression required is because of the variable length arrays.
Mixed type variables and variable length arrays are are allowed in C99 and latter. Neither MSVC nor Turbo C++ supports C99.
I tried to run my code online compiler but its not giving me these error there.
This is because almost all new (and online) C compilers support C99.
Related
This question already has answers here:
Finding unused enum members in C
(3 answers)
Closed 1 year ago.
Is there a warning or some other technique/mechanism/tooling to clean up a C code from unused enumerations?
A solution for C++ code would also be interesting but the question is primarily about C.
Ideally if the solution was to be found based on GNU tools available in common tool chains.
Any compiler or other code analysis tool that is capable of listing unused enumeration members would be interesting to know about.
I am currently using gcc. -Wall is on. No warnings about unused enumeration members appear in the compilation log.
Thanks to an unknown user in the comments there is an answer. Apparently a tool named Splint is capable of finding unused enumeration members.
Here is a similar question Finding unused enum members in C asked before, where the aforementioned tool has been analyzed and accepted as a correct answer.
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 5 years ago.
Improve this question
I am trying to make the compiler warning warning: too many arguments in call to 'IF' an error (where IF is a function).
I am having trouble configuring clang, as I cannot figure out the actual name of the warning.
I tried the following:
clang -Werror=too-many-arguments main.c
warning: unknown warning option '-Werror=too-many-arguments'; did you mean '-Werror=unknown-argument'?
[-Wunknown-warning-option]
But that just produces the warning above.
With
clang -Werror main.c
The warning does become an error, but I am trying to make only this specific warning an error.
How do I find the name of this compiler warning so I can promote it to a compiler error?
Thanks.
I checked the current sources in Subversion and found this: test/Misc/warning-flags.c in the Clang sources list warn_call_wrong_number_of_arguments (the internal code for this warning), which means that that it is expected that this warning has no separate -W flag. I'm sure the Clang developers would accept a patch which introduces an explicit name for this option.
But until that, -Werror is your only option.
-Werror is turning all warnings into errors. You could turn off all warnings except for that particular one you are interested in, but that is wrong on so many levels, I mention it only for academic reasons.
You might also consider getting a good lint, such as Gimpel's FlexeLint product. This is a lint with completely configurable warnings, errors and informational messages.
This does not directly answer your question, but I believe I can provide a better solution than what you're looking for.
This:
void test () {
printf("test\n");
}
is an old-style non-prototype function definition. As a definition, it specifies that the function has no parameters, but as a declaration, it does not specify the number and types of any expected arguments. Given this definition, a call that incorrectly passes an argument, like test("test") or test(42), is not a constraint violation and does not require a diagnostic, even though such a call has undefined behavior if it's evaluated.
clang is going above and beyond the language requirements to warn you about the incorrect call. (I'm mildly surprised it does so. gcc, for example, does not.)
This kind of thing is exactly why prototypes were added to the language back in 1989. As you mention in the question, you can define the function like this:
void test(void) {
printf("test\n");
}
Given that this definition is visible, a conforming compiler must diagnose any attempt to call this function incorrectly with one or more arguments.
The solution to your problem is not to coax the compiler into diagnosing a problem that the language doesn't require it to diagnose. It's to fix the code. There is very rarely a good reason not to use prototypes for all function declarations and definitions.
Old-style declarations and definitions are obsolescent, but they're still legal even in the 2011 version of ISO C. (I personally consider this unfortunate.)
(You say you don't want to specify void as a parameter, but you haven't explained why.)
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 5 years ago.
Improve this question
I read that dynamic semantic errors cannot be detected by the C compiler as semantic analysis phase catches only static semantic errors.
Then which component of C compiler does the checking of dynamic semantic errors?
which component of C compiler does the checking of dynamic semantic errors?
No phase. They are detected at runtime, if at all, by definition.
By dynamic semantic error, I mean accessing an index of array (out of bounds).
There is no such check in C.
I read somewhere that compiler generates code for checking dynamic semantic errors.
Not in C.
I am not sure what it meant.
Nothing in the case of C. Possibly you were reading about some other language. In any case the dynamic semantic check is still executed at runtime, not by any compiler phase.
As for my understanding the dynamic semantic errors can be discovered only during the runtime. C does not have any mechanisms for it, as C does not allow any dynamic semantics at all :) It is not an interpreted or JIT comiled language.
If you provide a real example of the dynamic semantic error in C, it will clarify what you actually mean
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 6 years ago.
Improve this question
See
http://pubs.opengroup.org/onlinepubs/009696699/basedefs/sys/socket.h.html
(http://pubs.opengroup.org/onlinepubs/9699919799 is from Issue 7 - from 2013 and still the same!)
sockaddr_storage is meant to be cast to other structure types,
but that contradicts the ANSI and ISO C standards aliasing rules
as far as I can tell. (Objects may not be accessed through
pointers to incompatible types, with the exception that anything
can be accessed through the 3 char types and that the structure
and its first member are interchangeable.)
I know that that practice of working with sockets existed long
before C was standardised, but POSIX is supposed to conform to
ISO C and actually it contradicts the standards in its manual. (Even in the
newer versions of POSIX.)
Why did they make it like this in the first place?
Why didn't they change it?
The strict-aliasing rules in the standard constrain user code, not implementation code. Since the POSIX headers and libraries are part of the implementation, there is no actual conflict between the POSIX and the C standard.
In an open-source platform, and in particular in Linux where the C library and compiler are developed by different teams, this makes life difficult for implementors, but that is their concern, not yours. For example, the implementors could:
refrain from exposing the potential conflict between the standards (that is, disable strict-aliasing optimizations);
admit that their implementation is not POSIX compliant (and note that, for example, there are no POSIX-certified Linux distributions);
provide facilities to ensure that the potentially conflicting facilities do not actually conflict. From the point of view of the C standard, this would be an extension.
This last option is how the gcc and glibc teams are working to resolve the sockaddr issue; see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255
As a matter of fact, I do not think there is a violation of strict aliasing rule here. Yes, you cast it to a different type when you call a function, but who said it has to be accessed through pointer of this type?
Protocol implementations know the proper type of the structure, so when they access the structure, they convert it back to the proper type. Conversion here is only used for passing pointer from one routine to another, but converted type is not used to access the data.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
What is the meaning that printf and scanf commands are the part of C language, as they don't need inclusion of #include<stdio.h>.
Why aren't others part of the C language?
What is the mean that,(print f) and (scan f) commands are the part of c language
They are not "commands", but rather functions, and they aren't part of the language either.
they don't need inclusion of #include
They do. They need the headers/declarations even more than others, since they are variadic. Not providing a prototype for them will quickly lead to undefined behavior.
why don't others be the part of c language
Again, these aren't part of the language because... because they are not part of the language. They are stand-alone functions, which don't contribute to the core syntax and semantics of a C program. They aren't included in C's context-free grammar. The C standard does describe them, though - since they are part of the C standard library.
Actually, no, they are not part of the language in the way you think they are. If you call print("hello, %d", 5); it will create an implicit declaration based on the parameters you've provided and the returning type will be int.
Luckily, there is a match for this in libc which is implicitly linked to your program, and linker will be able to link your source file and the library definition of printf.
In certain IDE, it is possible that printf & scanf are used and not underlined as false while editig the source code, because of the indexer which knows these functions exists. But you will not be able to compile it. The include is not optional as the compiler itselfs doesn't know printf nor scanf.
printf() and scanf() Example programs
In layman language
printf() is a function use to display (output)
scanf() is a function used for reading any input
printf and scanf aren't part of the grammar, but they are part of the language by virtue of being in the standard library as specified by the language definition. You do need to include stdio.h to use them properly, though.