I can only find the grammar of translation unit in section 6.9 which is as the follows:
translation-unit: external-declaration
translation-unit external-declaration
From this grammar, it seems that there should be at least one external declarations, which implies that an empty translation unit is not allowed. However, I would like to know what is required for a compiler to do for such a scenario. Can any one point me to the description in C11 if there is one?
Given that definition of a translation-unit, attempting to treat a empty source file as a translation unit results in a syntax error.
Section 5.1.1.3 of the C11 standard (see the N1570 draft) requires a diagnostic for a translation unit that violates a syntax rule or constraint. If the diagnostic is a non-fatal warning and the implementation translates it anyway, the resulting behavior is undefined by omission (4p2). If an implementation fails to issue a diagnostic message, the implementation is non-conforming (at least in the mode in which you invoked it), and the standard has nothing more to say about it.
Although the behavior of a particular implementation doesn't directly answer questions about what the language standard says, here's what gcc and clang do with an empty source file (with options to tell them to attempt to conform to C11):
$ gcc -c -std=c11 -pedantic-errors empty.c
empty.c:1:0: error: ISO C forbids an empty translation unit [-Wpedantic]
$ clang -c -std=c11 -pedantic-errors empty.c
empty.c:1:1: error: ISO C requires a translation unit to contain at least one declaration [-Werror,-Wempty-translation-unit]
^
1 error generated.
$
Related
I'm trying to get the gfortran compiler working in MATLAB on Windows to create mex files. Gfortran isn't supported, but the Intel Fortran compiler is, which leads me to believe that a Fortran compiler should be able to compile Fortran source using MATLAB libraries.
As detailed in my previous question, I get an "undefined reference" error for every symbol that should come from the MATLAB libraries. I thought this was an error with the preprocessor not getting invoked as suggested in a question on MathWorks Answers, but after looking into this problem some more I don't believe that's the problem since the errors refer to things like "mxisnumeric800" which is a substitution made in the fintrf.h header.
I checked the symbols exported from the required libraries, libmx.dll and libmex.dll, using dumpbin. The exported symbols include two that are close to mxisnumeric800:
Section contains the following exports for libmx.dll
...
1431 596 0009F200 MXISNUMERIC800
...
1747 6D2 000ABC24 mxIsNumeric_800
...
I can understand why mxIsNumeric_800 wouldn't be read as the same symbol due to the extra underscore, but does capitalization make a difference too?
The problem you are having is that Fortran is a case insensitive language. So if you have a subroutine foo:
subroutine foo(x)
real :: x
end subroutine foo
you could call it with any of the following:
call foo(x)
call FOO(x)
call fOo(x)
When you build an object file or library with this function, the symbol name will be compiler dependent. In case of Gfortran on a Linux system, it will always downcase the symbol name and add an underscore behind it such as
foo_
On Windows Systems it will behave differently (see here and here), and even different compilers will have different ideas.
So what now, what does this all mean?
This means that when you write a subroutine call like:
call mxIsNumeric_800(arg1, arg2, arg3)
Gfortran will attempt to link it against a symbol mxisnumeric_800_ and not the symbol you expect. In the past, this often resulted into ugly hacks which were very not-portable. Fortran 2003, addressed this issue in a clear way by introducing the BIND attribute. An attribute which allows the programmer to inform the compiler that this object should be handled as a non-Fortran object (cfr. Section 15.5 of the F2008 standard).
With this attribute, you can now define an interface that is fully understood by Fortran and that the compiler knows where to find the corresponding symbol with its respective case-sensitivity. Eg.
interface
subroutine mxisnumeric(arg1,arg2,arg3) BIND(C, NAME="mxIsNumeric_800")
use, intrinsic :: iso_c_binding
implicit none
real(c_float) :: arg1
integer(c_int) :: arg2
character(c_char) :: arg3
end subroutine mxisnumeric
end interface
Some more details can be found here.
In versions through 1.2 of the SMT-LIB language, overloading of user-defined symbols was allowed. Since version 2.0 of standard, overloading is restricted to theory symbol.
Nevertheless, some SMT-solvers still allow overloading of user-defined symbols and that happens to be handy for my use case: proof obligations are easily generated automatically with overloading, not so much without... I would like to add cvc4 to my portfolio of SMT solvers, but I found out that it produces a parsing error on overloaded user-symbols.
I am aware that this is the correct way to be compliant with the SMT-LIB standard, but I would like to know the following: Is there an option to CVC4 that disables such check and where the parser is able to disambiguate overloaded user symbols?
Unfortunately, CVC4 does not have an option to support overloaded user symbols. Each user symbol must be unique.
I am attempting to use clock_gettime( CLOCK_MONOTONIC, ts ). I have included time.h, and linked to librt (I think). I still get the error that CLOCK_MONOTONIC is undefined. (EDIT: error text added)
Symbol 'CLOCK_MONOTONIC' could not be resolved ... Semantic Error
c++ in eclipse. In myrojname->properties->C/C++ Build->GCC C++ Linker->libraries I added "rt". The resulting command line includes -lrt.
I tried a much simpler scratch program and compiled from the command line with g++ -o mytest mytest.cpp -lrt and it works great.
So, what am I missing?
I think that's actually an error message coming out of the CDT static analyser, not something from the compiler itself.
And I think it's complaining about the code itself rather than something missing from the linkage objects, so whether you link with rt or not is not relevant (for this particular issue anyway).
You should go into the C++ settings, specifically the include paths, and ensure that all needed directories are listed there.
The following preprocessor macro:
#define _VARIANT_BOOL /##/
is not actually valid C; roughly speaking, the reason is that the preprocessor is defined as working on a stream of tokens, whereas the above assumes that it works on a stream of characters.
On the other hand, unfortunately the above actually occurs in a Microsoft header file, so I have to handle it anyway. (I'm working on a preprocessor implementation.)
What other cases have people encountered in the wild, be it in legacy code however old as long as that code may be still in use, of preprocessor macros that are not actually valid, but work anyway because they were written under compilers that use a character oriented preprocessor implementation?
(Rationale: I'm trying to get some idea in advance how many special cases I'm going to have to hack, if I write a proper clean standard-conforming token oriented implementation.)
The relevant part of the standard (ยง6.10.3.3 The ## operator) says:
If the result is not a valid preprocessing token, the behavior is undefined.
This means that your preprocessor can do anything it likes and still be standard conforming, including emulating the common behaviour.
I think you can still have a "token-based" implementation and support this behaviour, by specifying that when the result of the ## operator is not a valid preprocessing token, the result is the two operand tokens unchanged. You may also want to have your preprocessor emit a warning about the invalid code.
I am compiling my C90 c code in gcc . I am getting the warningISO C90 forbids variable-size array while making the declaration like
int symbols[nc];
Where nc is integer whose value is read from the input file. The values on the input files are varied so i can't keep a constant value. How can I get rid of it? Is it indeed necessary to resolve this warning or we can simply ignore it?
Thanks in advance.
You get that warning because C90 does not support variable length arrays.
You'll either have to switch gcc to C99 mode (which does support vla) , by using the -std=c99 or std=gnu99 command line flag, or rewrite your code to dynamically allocate memory or use a fixed size array.
The warning just tells you that you're not conforming to C90 in this case, but it's otherwise safe. Ignoring a warning should really not be an option though.