I run debian linux actual stable with splint and mingw installed.
I want to check my c code (which I need to compile with mingw, sorry) by splint. Simply adding the mingw-includes is not enough to run. I tried with defining GNU and i686 - but I'm sure more is needed. What further do I have to define or include?
I tried the idea from loan resulting in a problem with __builtin_va_list.
Splint 3.1.2 --- 20 Feb 2009
/usr/i686-w64-mingw32/include/vadefs.h:24:43: Parse Error:
Suspect missing struct or union keyword: __builtin_va_list :
int. (For help on parse errors, see splint -help parseerrors.)
*** Cannot continue.
The funny thing is, that I can not find any definition for not - even with a recursive grep on the include folders. Am I searching wrong?
By defining it the way -D__builtin_va_list=va_list (from benjarobin) I ran into the error
Splint 3.1.2 --- 20 Feb 2009
/home/ebelingb/.splintrc:229:1: Setting -stats redundant with current value
/home/ebelingb/.splintrc:229:1: Setting -showsummary redundant with current
value
/usr/i686-w64-mingw32/include/winnt.h:2390:15:
Parse Error. (For help on parse errors, see splint -help parseerrors.)
*** Cannot continue.
which could not be recovered even by +trytorecover.
The lines from winnt.h (and neighbouring) reads
2388 typedef struct _EXCEPTION_POINTERS {
2389 PEXCEPTION_RECORD ExceptionRecord;
2390 PCONTEXT ContextRecord;
2391 } EXCEPTION_POINTERS,*PEXCEPTION_POINTERS;
Strange, isn't it?
Okay as this thread gets no further answers, I'll give some motivation by this minimal not working example:
Given a file test.c
#include <windows.h>
#include <stdio.h>
#include <time.h>
#define LOGFILEFORMAT "C:\\CBM\\log\\%Y%m%d.log"
#define LOGTIMESTAMPFORMAT "%Y-%m-%d %H:%M:%S"
int main() /*int argc,char **argv*/{
Sleep(1234);
return (0);
}
and my .splintrc
-I/usr/lib/gcc/i686-w64-mingw32/4.6/include
-I/usr/lib/gcc/i686-w64-mingw32/4.6/include-fixed
-I/usr/i686-w64-mingw32/include
the easy command splint test.c fails:
Splint 3.1.2 --- 20 Feb 2009
/usr/i686-w64-mingw32/include/_mingw.h:480:29: Parse Error:
Suspect missing struct or union keyword: __int64 :
long int. (For help on parse errors, see splint -help parseerrors.)
*** Cannot continue.
Again I do not know, how to setup. The includes above result from a preprocesing call of the compiler i686-w64-mingw32-gcc, which runs fine on test.c.
You can get a good list of preprocessor defines using a blank C source file and running it through GCC/MinGW with your desired custom arguments:
gcc -E -P -v -dD [optional arguments] blank.c
Be sure to use the proper compiler for your target. You can redirect the output to a file and pass whatever defines you may need from there to splint.
Related
I have some C code that includes a header for a propriety legacy application. I cannot modify the header. I'm receiving a splint Parse Error for the following code:
#if defined(HAS_LONGLONG)
/* removed for brevity */
#elif defined(HAS_INT64)
/* removed for brevity */
#else
typedef union {
int32 l[2]; /* This is the line that is causing the parse error in splint */
double d;
} int64;
#endif
Is there any parameter I can pass to splint to get this working?
The platform is 64 bit but the legacy application is 32 bit.
I'm running splint like:
[me#host]$ splint -I/path/to/include -preprox -warnposix
Splint 3.1.1 --- 28 Apr 2003
/path/to/include/some_header.h:7:10:
Parse Error. (For help on parse errors, see splint -help parseerrors.)
*** Cannot continue.
Without -preprox and -warnposix I get a lot of other errors in the legacy header.
You should pass -Dint32=int.
The splint FAQ states this:
I develop code on an embedded system with a compiler that uses nonstandard key words and data types. I would like to run Splint on my code but these nonstandard keywords cause parse errors. What should I do?
You can often use -D to solve this problem.
If you just want to ignore a keyword, you can add -Dnonstandardkeyword= to make the preprocessor eliminate the keyword, where nonstandardkeyword is the name of the keyword. Similarly, you can use -Dspecialtype=int to make a custom type parse as an int.
Is there a way to stop splint from analyzing system headers included, POSIX, libc etc.? I run with -warnposix -preproc:
% splint -warnposix -preproc my.c
/usr/include/unistd.h:220:8: Parse Error: Non-function declaration:
__BEGIN_DECLS : int. (For help on parse errors, see splint -help
parseerrors.)
*** Cannot continue.
UPDATE:
% splint +posixlib +unixlib -I/path/to/myheaders -I/usr/include/x86_64-linux-gnu my.c
/usr/include/asm-generic/int-ll64.h:19:24: Parse Error:
Suspect missing struct or union keyword: __signed__ :
int. (For help on parse errors, see splint -help parseerrors.)
After reading splint FAQ14 I tried to eliminate nonstandard keyword:
% splint +posixlib +unixlib -D__signed__= -I/path/to/myheaders -I/usr/include/x86_64-linux-gnu my.c
/usr/include/x86_64-linux-gnu/sys/syslog.h:200:66: Parse Error:
Inconsistent function parameter syntax: __gnuc_va_list :
<any>. (For help on parse errors, see splint -help parseerrors.)
*** Cannot continue.
Declaring __gnuc_va_list as nonstandard keyword doesn't help in this particular case. I feel that splint is a powerful tool, but it requires to annotate almost every code it parses. Am I wrong?
A little background:
I'm trying to port some .ksh files that I have running on Solaris to run on Windows using Cygwin. There is a difference between the ksh implementation running on the Solaris box and the pdksh implementation that is easily installable in Cygwin that deals with subshells - you can check this question for the details if you'd like.
Because of this difference, I'm trying to build the AST toolkit found here because the binaries are no longer available from AT&T according to this question.
My Question:
When I try to build according to the instructions on the GitHub site, I wind up with an error compiling a file called fastfind.c:
+ cc -D_BLD_STATIC -D_BLD_DLL -D_BLD_ast -I. -I/ast-master/src/lib/libast -Icomp -I/ast-master/src/lib/libast/comp -Imisc -I/ast-master/src/lib/libast/misc -Iinclude -I/ast-master/src/lib/libast/include -Istd -I/ast-master/src/lib/libast/std -D_PACKAGE_ast -c /ast-master/src/lib/libast/misc/fastfind.c,
In file included from /ast-master/src/lib/libast/std/stdio.h:22:0,
from ./ast_wchar.h:87,
from /ast-master/src/lib/libast/include/regex.h:39,
from /ast-master/src/lib/libast/misc/findlib.h:35,
from /ast-master/src/lib/libast/misc/fastfind.c:77:
./ast_stdio.h:82:15: error: conflicting types for '_sfio_FILE'
#define FILE _sfio_FILE
^
./ast_stdio.h:80:24: note: previous declaration of '_sfio_FILE' was here
typedef struct _sfio_s _sfio_FILE;
^
mamake [lib/libast]: *** exit code 1 making fastfind.o
Lines 80-82 of the file ast_stdio.h are as follows:
80: typedef struct _sfio_s _sfio_FILE;
81:
82: #define FILE _sfio_FILE
Also, the top of the ast_stdio.h file have this:
/* : : generated by proto : : */
/* : : generated from /ast-master/src/lib/libast/features/stdio by iffe version 2012-07-17 : : */
Lastly, here's my relevant cc information:
$ cc --version
cc (GCC) 5.4.0
A little disclaimer: my C is rusty as I've been a Java guy for the past 14 years. My understanding is that the #define directive gets evaluated by the preprocessor, so line 82 would essentially replace the string FILE with _sfio_FILE in the code, and the typedef line wouldn't be evaluated until actual compilation.
Obviously I'm wrong, or this error wouldn't be happening. And obviously this code compiles for someone, or it wouldn't have been released this way. Any insights as to what's going on here and how I can make this file compile are appreciated. I found this question which seems close to what I'm asking, but there's either something different between my case and that question's, or my C brain is not able to comprehend why that question should cover my particular situation.
Thanks for your time!
The error was due to a change in glibc. See Red Hat Bugzilla #1477082 for more information and what changes to source files are needed.
Looking into learning C. As I understand it when I say #include <stdio.h> it grabs stdio.h from the default location...usually a directory inside your working directory called include. How do I actually get the file stdio.h? Do I need to download a bunch of .h files and move them from project to project inside the include directory? I did the following in a test.c file. I then ran make test and it outputted a binary. When I ran ./test I did not see hello print onto my screen. I thought I wasn't seeing output maybe because it doesn't find the stdio.h library. But then again if I remove the greater than or less than signs in stdio the compiler gives me an error. Any ideas?
I'm on a Mac running this from the command line. I am using: GNU Make 3.81. This program built for i386-apple-darwin10.0
#include <stdio.h>
main()
{
printf("hello");
}
Edit: I have updated my code to include a datatype for the main function and to return 0. I still get the same result...compiles without error and when I run the file ./test it doesn't print anything on screen.
#include <stdio.h>
int main()
{
printf("hello");
return 0;
}
Update:
If I add a \n inside of the printf it works! so this will work:
#include <stdio.h>
int main()
{
printf("hello\n");
return 0;
}
Your code should have preferably
printf("hello\n");
or
puts("hello");
If you want to know where does the standard header file <stdio.h> comes from, you could run your compiler with appropriate flags. If it is gcc, try compiling with
gcc -H -v -Wall hello.c -o hello
Pedantically, a standard header file is even not required to exist as a file; the standard permits an implementation which would process the #include <stdio.h> without accessing the file system (but e.g. by retrieving internal resources inside the compiler, or from a database...). Few compilers behave that way, most really access something in the file system.
If you didn't have the file, you'd get a compilation error.
My guess is the text was printed, but the console closed before you got the chance to see it.
Also, main returns an int, and you should return 0; to signal successful completion.
#include <header.h>, with angle brackets, searches in standard system locations, known to the compiler-- not in your project's subdirectories. In Unix systems (including your Mac, I believe), stdio.h is typically in /usr/include. If you use #include "header.h", you're searching subdirectories first and then the same places as with <header.h>.
But you don't need to find or copy the header to run your program. It is read at compilation time, so your ./test doesn't need it at all. Your program looks like it should have worked. Is it possible that you just typed "test", not "./test", and got the system command "test"? (Suggestion: Don't name your programs "test".)
Just going to leave this here : STILL! in 2018, December... Linux Mint 18.3
has no support for C development.
innocent / # cc ThoseSorts.c
ThoseSorts.c:1:19: fatal error: stdio.h: No such file or directory
compilation terminated.
innocent / # gcc ThoseSorts.c
ThoseSorts.c:1:19: fatal error: stdio.h: No such file or directory
compilation terminated.
innocent / # apt show libc6
(Abbreviated)::
Package: libc6
Version: 2.23-0ubuntu10
Priority: required
Section: libs
Source: glibc
Origin: Ubuntu
Installed-Size: 11.2 MB
Depends: libgcc1
Homepage: http://www.gnu.org/software/libc/libc.html
Description: GNU C Library: Shared libraries
Contains the standard libraries that are used by nearly all programs on
the system. This package includes shared versions of the standard C library
and the standard math library, as well as many others.
innocent / # apt-get install libc6-dev libc-dev
So, magic... and a minute later they are all installed on the
computer and then things work as they should.
Not all distros bundle up all the C support libs in each ISO.
Hunh.
hardlyinnocent / # gcc ThoseSorts.c
hardlyinnocent / # ./a.out
20
18
17
16
... ... ...
I have been trying to compile netcat.c on AIX for some time (using the command make aix), but the compiler gives me some weird feedback such as :
"netcat.c", line 117.12: 1506-275 (S) Unexpected text 'int' encountered.
when checked the file netcat.c at line 117, I would find the line (second line in code below):
#ifdef HAVE_BIND
extern int h_errno;
/* stolen almost wholesale from bsd herror.c */
even if I changed the int into char for the same of testing, save the file and re-run the command I get the same error
am I missing something in reading the error code?
If you're using xlc (especially older ones), it's normally caused by declarations after statements, something like:
i = i + 1;
int x;
You probably need to give us a little more context, such as 10 or so lines before the error line.
My advice would be to get gcc running on that box if you are using an older xlc. IBM makes some fine compilers now but the earlier ones weren't so crash hot (in my opinion).
When innocent-looking code produces bizarre errors, try running the code through the C preprocessor stage, and looking at it then. Sometimes macros do very funny things.
Also note that a problem on an earlier line (missing semicolon, etc.) might produce an error message on a later line.
The post maybe already a little outdated, but just in case someone else comes along with the same problem ...
Here (AIX 7.1) h_errno is defined as macro in netdb.h.
/usr/include/netdb.h:#define h_errno (*(int *)h_errno_which())
Therefore the declaration in netcat.c line 117 does not work.
I just changed the line into
#ifndef h_errno
extern int h_errno;
#endif
and the compilation worked smoothly.
#A.Rashad, I moved the HAVE_BIND #ifdef block from line 117 to line 30 which is just under the #include "generic.h" declaration. This permitted the xlc to compile it. The (S)yntax error messages are gone and while there are some (W)arning messages, I do get an nc binary at the end!
hth,
Kevin