If this is the wrong place for this question I apologise and please redirect me to the suitable section.
I'm somewhat rusty on installing from command line, especially on Windows. I decided to install the latest Perl version on my PC, running under Windows 10. I had previously installed it using Strawberry Perl download, but as it was a few versions out of date I decided to remove it and refresh my skills (ha) by installing it manually. I downloaded the lastest Perl release from https://www.perl.org/get.html#win32 and have been reading the README.win32 to make sure I install it correctly.
As I need a compiler, I decided to use Gcc and dmake. I installed and can run them successfully so went back to installing Perl. As per instructions I tried running dmake in the win32 subdirectory in the Perl download folder. Before this I edited makefile.mk, where these variables are uncommented from the Build configuration section:
INST_DRV/INST_TOP (left as is)
INST_VER *= \5.26.0
USE_MULTI *= define
USE_ITHREADS *= define
USE_IMP_SYS *= define
USE_LARGE_FILES *= define
USE_64_BIT_INT *= define
USE_LONG_DOUBLE *= define
DEFAULT_INC_EXCLUDES_DOT *= define
CCTYPE = GCC
GCCWRAPV *=define
CCHOME *= C:\MinGW
(nothing else changed after this)
When I run dmake in the directory, it quickly comes to this error:
gcc -c -I.\include -I. -I.. -DWIN32 -DPERLDLL -DPERL_CORE -s -O2 -
D__USE_MINGW_ANSI_STDIO -fwrapv -fno-strict-aliasing
-DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -omini\toke.o ..\toke.c
In file included from ..\perl.h:3220:0,
from ..\toke.c:40:
./win32.h:417:13: error: conflicting types for 'mkstemp'
extern int mkstemp(const char *path);
^~~~~~~
In file included from ..\perl.h:790:0,
from ..\toke.c:40:
c:\mingw\include\stdlib.h:809:30: note: previous definition of 'mkstemp' was here
__cdecl __MINGW_NOTHROW int mkstemp (char *__filename_template)
^~~~~~~
In file included from ..\toke.c:40:0:
..\toke.c: In function 'Perl_filter_add':
..\perl.h:1756:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
#define PTR2nat(p) (PTRV)(p) /* pointer to integer of PTRSIZE */
^
..\perl.h:1769:28: note: in expansion of macro 'PTR2nat'
#define FPTR2DPTR(t,p) ((t)PTR2nat(p)) /* function pointer to data pointer */
^~~~~~~
..\toke.c:4397:21: note: in expansion of macro 'FPTR2DPTR'
IoANY(datasv) = FPTR2DPTR(void *, funcp); /* stash funcp into spare field */
^~~~~~~~~
..\perl.h:1769:25: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#define FPTR2DPTR(t,p) ((t)PTR2nat(p)) /* function pointer to data pointer */
^
..\toke.c:4397:21: note: in expansion of macro 'FPTR2DPTR'
IoANY(datasv) = FPTR2DPTR(void *, funcp); /* stash funcp into spare field */
^~~~~~~~~
..\toke.c: In function 'Perl_filter_del':
..\perl.h:1756:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
#define PTR2nat(p) (PTRV)(p) /* pointer to integer of PTRSIZE */
^
..\perl.h:1769:28: note: in expansion of macro 'PTR2nat'
#define FPTR2DPTR(t,p) ((t)PTR2nat(p)) /* function pointer to data pointer */
^~~~~~~
..\toke.c:4463:26: note: in expansion of macro 'FPTR2DPTR'
if (IoANY(datasv) == FPTR2DPTR(void *, funcp)) {
^~~~~~~~~
..\perl.h:1769:25: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#define FPTR2DPTR(t,p) ((t)PTR2nat(p)) /* function pointer to data pointer */
^
..\toke.c:4463:26: note: in expansion of macro 'FPTR2DPTR'
if (IoANY(datasv) == FPTR2DPTR(void *, funcp)) {
^~~~~~~~~
..\toke.c: In function 'Perl_filter_read':
..\perl.h:1756:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
#define PTR2nat(p) (PTRV)(p) /* pointer to integer of PTRSIZE */
^
..\perl.h:1768:28: note: in expansion of macro 'PTR2nat'
#define DPTR2FPTR(t,p) ((t)PTR2nat(p)) /* data pointer to function pointer */
^~~~~~~
..\toke.c:4554:13: note: in expansion of macro 'DPTR2FPTR'
funcp = DPTR2FPTR(filter_t, IoANY(datasv));
^~~~~~~~~
..\perl.h:1768:25: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#define DPTR2FPTR(t,p) ((t)PTR2nat(p)) /* data pointer to function pointer */
^
..\toke.c:4554:13: note: in expansion of macro 'DPTR2FPTR'
funcp = DPTR2FPTR(filter_t, IoANY(datasv));
^~~~~~~~~
In file included from ..\perl.h:5644:0,
from ..\toke.c:40:
..\toke.c: In function 'S_pending_ident':
..\perl.h:1734:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
# define INT2PTR(any,d) (any)(d)
^
..\embed.h:427:59: note: in definition of macro 'newUNOP_AUX'
#define newUNOP_AUX(a,b,c,d) Perl_newUNOP_AUX(aTHX_ a,b,c,d)
^
..\toke.c:8912:37: note: in expansion of macro 'INT2PTR'
INT2PTR(UNOP_AUX_item *,
^~~~~~~
I get a bunch of warnings beforehand about casting from pointers to integers of different sizes, but this is the bit where it stops and produces an error. Am I missing something obvious? I haven't done this for a while, so I'm hoping it is a silly user error on my part! Thanks.
Try obtaining the MinGW source packages, and installing using makepkg-mingw to build them.
Most if not all have patches applied to customize (or fix) them for the MSYS2/MinGW environment.
Stock source downloaded from its author may not compile directly in that environment the way it would on Linux, or OS X using "configure" and "make".
Instructions are available, and there may be other similar instructions out there associated with Arch Linux.
Related
I am getting the following error
rudimentary_calc.c: In function ‘main’:
rudimentary_calc.c:9:6: error: conflicting types for ‘getline’
9 | int getline(char line[], int max) ;
| ^~~~~~~
In file included from rudimentary_calc.c:1:
/usr/include/stdio.h:616:18: note: previous declaration of ‘getline’ was here
616 | extern __ssize_t getline (char **__restrict __lineptr,
| ^~~~~~~
when I ran the following code
#include <stdio.h>
#define maxline 100
int main()
{
double sum, atof(char[]);
char line[maxline];
int getline(char line[], int max) ;
sum = 0;
while (getline(line, maxline) > 0)
printf("\t %g \n", sum += atof(line));
return 0;
}
What am I doing wrong? I am very new to C, so I don't know what went wrong.
Generally, you should not have to declare "built-in" functions as long as you #include the appropriate header files (in this case stdio.h). The compiler is complaining that your declaration is not exactly the same as the one in stdio.h.
The venerable K&R book defines a function named getline. The GNU C library also defines a non-standard function named getline. It is not compatible with the function defined in K&R. It is declared in the standard <stdio.h> header. So there is a name conflict (something that every C programmer has do deal with).
You can instruct GCC to ignore non-standard names found in standard headers. You need to supply a compilation flag such as -std=c99 or -std=c11 or any other std=c<year> flag that yout compiler supports.
Live demo
Always use one of these flags, plus at least -Wall, to compile any C code, including code from K&R. You may encounter some compiler warnings or even errors. This is good. Thy will tell you that there are some code constructs that were good in the days of K&R, but are considered problematic now. You want to know about those. The book is rather old and the best practices and the C language itself have evolved since.
I'm in the process of setting up a project. I have skeleton tests in place using boost unit-test. Unfortunately a large number of warnings are spawned from the macro expansions. Is there a way to disable these, without have to specify individual line numbers?.
This occurs even when I have a // NOLINT.
An example:
/home/peter/checkouts/canopen-gateway/./unittests/projs/server/exe/testunit-tcp-socket.cpp:12:1: warning: construction of 'end_suite12_registrar12' with static storage duration may throw an exception that cannot be caught [cert-err58-cpp]
BOOST_AUTO_TEST_SUITE_END() // NOLINT
^
/usr/include/boost/test/unit_test_suite.hpp:62:73: note: expanded from macro 'BOOST_AUTO_TEST_SUITE_END'
#define BOOST_AUTO_TEST_SUITE_END() \
^
/usr/include/boost/test/unit_test_suite.hpp:209:62: note: expanded from macro '\BOOST_AUTO_TU_REGISTRAR'
static boost::unit_test::ut_detail::auto_test_unit_registrar BOOST_JOIN( BOOST_JOIN( test_name, _registrar ), __LINE__ )
^
/usr/include/boost/config/suffix.hpp:544:28: note: expanded from macro 'BOOST_JOIN'
#define BOOST_JOIN( X, Y ) BOOST_DO_JOIN( X, Y )
^
/usr/include/boost/config/suffix.hpp:545:31: note: expanded from macro 'BOOST_DO_JOIN'
#define BOOST_DO_JOIN( X, Y ) BOOST_DO_JOIN2(X,Y)
^
/usr/include/boost/config/suffix.hpp:546:32: note: expanded from macro 'BOOST_DO_JOIN2'
#define BOOST_DO_JOIN2( X, Y ) X##Y
^
note: expanded from here
/usr/include/boost/test/unit_test_suite_impl.hpp:284:17: note: possibly throwing constructor declared here
explicit auto_test_unit_registrar( int );
You probably didn't paste the entire error message, but somewhere in there should be a line that says
warning: disabled expansion of recursive macro
[-Wdisabled-macro-expansion]
You can disable this by passing -Wno-disabled-macro-expansion to the clang command line.
Try wrapping the offending code thus:
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wdisabled-macro-expansion"
// your code here
#pragma clang diagnostic pop
Whenever I compile my code I observe following two warnings:
warning: '<variable>' defined but not used
warning: unused variable '<variable>'
I tried to google but I did not find any helpful thread or blog about what is the difference between these two warnings.
Example with some sample code snippet will do for me or if am duplicating some existing thread please feel free to refer.
I think the difference is kind of subtle but here is the code snippet along with the compiler output that demonstrates some differences:
#include <iostream>
static const char * hello = "Hello";
void foo() {
int i;
std::cout << "foo" << std::endl;
}
...
argenet#Martell ~ % g++ /tmp/def_not_used.cpp -Wall
/tmp/def_not_used.cpp: In function ‘void foo()’:
/tmp/def_not_used.cpp:6:9: warning: unused variable ‘i’ [-Wunused-variable]
int i;
^
/tmp/def_not_used.cpp: At global scope:
/tmp/def_not_used.cpp:3:21: warning: ‘hello’ defined but not used [-Wunused-variable]
static const char * hello = "Hello";
So here the local variable is never used, therefore the compiler may simply omit it while generating the code and it emits an "unused variable" warning.
At the same time, the static C-style literal cannot be omitted that easily as it is available for a wider scope (the whole .cpp file).
However, it is not referenced by any code in this module so the compiler warns about it like "defined but not used".
I am attempting to build CryptoPP with Cygwin x86_64, but I'm having some trouble with osrng.cpp.
I'm using gcc's C++ compiler, and I'm getting the following error at line 50 of osrng.cpp
$ make
g++ -DNDEBUG -g -O2 -march=native -pipe -c osrng.cpp
osrng.cpp: In constructor ‘CryptoPP::MicrosoftCryptoProvider::MicrosoftCryptoProvider()’:
osrng.cpp:50:80: error: invalid conversion from ‘CryptoPP::MicrosoftCryptoProvider::ProviderHandle* {aka long unsigned int*}’ to ‘HCRYPTPROV* {aka long long unsigned int*}’ [-fpermissive]
if(!CryptAcquireContext(&m_hProvider, 0, 0, PROV_RSA_FULL, CRYPT_VERIFYCONTEXT))
^
In file included from /usr/include/w32api/windows.h:95:0,
from osrng.cpp:19:
/usr/include/w32api/wincrypt.h:646:26: error: initializing argument 1 of ‘WINBOOL CryptAcquireContextA(HCRYPTPROV*, LPCSTR, LPCSTR, DWORD, DWORD)’ [-fpermissive]
WINIMPM WINBOOL WINAPI CryptAcquireContextA(HCRYPTPROV *phProv,LPCSTR szContainer,LPCSTR szProvider,DWORD dwProvType,DWORD dwFlags);
^
GNUmakefile:208: recipe for target 'osrng.o' failed
make: *** [osrng.o] Error 1
I have successfully compiled the whole thing under the 32bit version of Cygwin before.
How can I fix this for the 64bit edition?
EDIT As suggested by #Yakov's answer, I replaced if defined(_WIN64)if defined(__x86_64__) by if in line 30 of osrng.h.
Sadly though, I immediately run into the next problem, indicated by the following error:
$ make
g++ -DNDEBUG -g -O2 -march=native -pipe -c fipstest.cpp
In file included from dll.h:30:0,
from fipstest.cpp:8:
osrng.h:34:19: error: expected ‘;’ at end of member declaration
typedef unsigned __int64 ProviderHandle; // type HCRYPTPROV, avoid #include <windows.h>
^
osrng.h:34:27: error: ‘ProviderHandle’ does not name a type
typedef unsigned __int64 ProviderHandle; // type HCRYPTPROV, avoid #include <windows.h>
^
osrng.h:38:2: error: ‘ProviderHandle’ does not name a type
ProviderHandle GetProviderHandle() const {return m_hProvider;}
^
osrng.h:40:2: error: ‘ProviderHandle’ does not name a type
ProviderHandle m_hProvider;
^
GNUmakefile:208: recipe for target 'fipstest.o' failed
make: *** [fipstest.o] Error 1
Thankfully, GCC error messages have improved significantly in recent releases. The {aka}s tell you that there is a mismatch between long and long long. Keep in mind that Win64 is LLP64: long is still only 32-bits, and you need a long long to match the size of a pointer. Most (all?) other 64-bit platforms are LP64, meaning that long matches the size of a pointer.
In this particular case, see the if defined(_WIN64) in osrng.h; you will need to change that condition to if defined(__x86_64__) instead.
You might run into problems with the __int64 type as well. Replace those with long long. (Occurs here, here and here.)
You might also find word64 useful. From Crypto++'s config.h:
#if defined(_MSC_VER) || defined(__BORLANDC__)
typedef unsigned __int64 word64;
#define W64LIT(x) x##ui64
#else
typedef unsigned long long word64;
#define W64LIT(x) x##ULL
#endif
There's a couple of Cygwin defines in there too. But they don't look interesting. For example:
#ifndef TYPE_OF_SOCKLEN_T
# if defined(_WIN32) || defined(__CYGWIN__)
# define TYPE_OF_SOCKLEN_T int
# else
# define TYPE_OF_SOCKLEN_T ::socklen_t
# endif
#endif
#if defined(__CYGWIN__) && defined(PREFER_WINDOWS_STYLE_SOCKETS)
# define __USE_W32_SOCKETS
#endif
(Sorry about the comment here. Its too bing to fit in the little comment block).
I have the following piece of code:
#include <stdlib.h>
#include <stdio.h>
void test(unsigned char * arg) { }
int main() {
char *pc = (char *) malloc(1);
unsigned char *pcu = (unsigned char *) malloc(1);
*pcu = *pc = -1; /* line 10 */
if (*pc == *pcu) puts("equal"); else puts("not equal"); /* line 12 */
pcu = pc; /* line 14 */
if (pcu == pc) { /* line 16 */
test(pc); /* line 18 */
}
return 0;
}
If I compile it with gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) (but it is not limited to this particular version) with options
gcc a.c -pedantic -Wall -Wextra -Wsign-conversion -Wno-unused-parameter; ./a.out
I get the following warnings
test.c: In function ‘main’:
test.c:10:21: warning: conversion to ‘unsigned char’ from ‘char’ may change the sign of the result [-Wsign-conversion]
test.c:14:13: warning: pointer targets in assignment differ in signedness [-Wpointer-sign]
test.c:16:17: warning: comparison of distinct pointer types lacks a cast [enabled by default]
test.c:18:17: warning: pointer targets in passing argument 1 of ‘test’ differ in signedness [-Wpointer-sign]
test.c:4:6: note: expected ‘unsigned char *’ but argument is of type ‘char *’
not equal
g++ warnings/errors are similar. I hope I understand why the comparison on line 12 is evaluated to false, but is there any way to get a warning also in such cases? If not, is there some principial difference between line 12 and the lines which cause warnings? Is there any specific reason why comparison of char and unsigned char shouldn't deserve its warning? Because at least at first glance, line 12 seems to me more "dangerous" than e.g. line 16.
A short "story behind": I have to put together pieces of code from various sources. Some of them use char and some of them use unsigned char. -funsigned-char would work fine, but I am forced to avoid it and rather to add proper type conversions. That's why such a warning would be useful for me, because now, if I forget to add a type conversion in such a case, the program silently fails.
Thanks in advance, P.
I believe this is caused by integer promotion.
When you deal with char or short, what C actually does (and this is defined by the standard, not the implementation) is promote those types to int before doing any operations. The theory, I think, is that int is supposed to be the natural size used by the underlying machine, and therefore the fastest, most efficient size; in fact, most architectures will do this conversion on loading a byte without being asked.
Since both signed char and unsigned char will fit happily within the range of a signed int, the compiler uses that for both, and the comparison becomes a pure signed comparison.
When you have a mismatched type on the left-hand-side of the expression (lines 10 and 14) then it needs to convert that back to the smaller type, but it can't, so you get a warning.
When you compared the mismatching pointers (line 16) and passed the mismatching pointer (line 18), the integer promotion is not in play because you never actually dereference the pointers, and so no integers are ever compared (char is an integer type also, of course).