In Atmelstudio 6.1 I debug my AVR 328
When opening Quickwatch I tried to analyze a problem and due to unexected problems I stripped down the problem to this:
Entered expression is (float)(1000), also tried with .0F
(float)(1000) 1148846080 float
(float)(1000.0F) 1148846080 float
What the heck is going wrong ?
This was a known bug in 6.1 and some of the 6.2 versions (fixed at least in the latest SP of 6.2). The number is the integer representation of the IEEE floating point number (showing the mantissa and exponent bitfields as a int).
Related
I want to use the below equation in one of the code
A = g^a mod p; //g raise to a modulus p.
(something like 2^5 % 3) = 32%3 = 2
(This equation looks like Diffie Hellman algorithm for security)
Where:
^ is (power)
g is fixed number 0x05
a is 128bit(16bytes) randomly generated number,
p is fixed hex number of 128bit(16bytes). Something like (0x0xD4A283974897234CE908B3478387A3).
I am using:
Qt 4.8.7
Compiler MinGW32 (checked with boost library boost 1.70)
The solutions which I found which didn`t work for me are listed below:
one can use __int128 but to support that one should have used
latest GCC compiler or MinGW64 bit compiler, neither of that I am using now.
I found one latest version of Qt has QSslDiffieHellmanParameters class,
but again not supported in our Qt version.
I found some libraries like boost/multiprecision/cpp_int.hpp (boost 1.70))
that does have data type such as int128_t and int256_t, but due to
our compiler isssue or something else, we are not able to store
128bit number, meaning
if I do:
int128_t ptval128 = 0xAB1232423243434343BAE3453345E34B;
cout << "ptval128 = " << std::hex << ptval128 << endl;
//will print only 0xAB12324232434343;//half digits only,
I tried using Bigint which much more useful, but again
5^(128bit number) is way too big, it takes hours to compute things,
(I waited till 1 hour and 16 mins and kill the application).
int myGval = 0x05;
128_bit_data_type myPVal= 0xD4A283974897234CE908B3478387A3;
128_bit_data_type 128_bit_variable = 128_bit_random_data;
myVal = (myGval)^(128_bit_variable) % (myPVal);
That is not how to do modular exponentiation! The first problem is that 5 ^ 128_bit_variable is huge, so big that it won't fit into memory in any computers available today. To keep the required storage space within bounds, you have to take the remainder % myPVal after every operation.
The second problem is that you can't compute 5 ^ 128_bit_variable simply by multiplying by 5 by itself 128_bit_variable times -- that would take longer than the age of the universe. You need to use an exponentiation ladder, which requires just 128 squarings and at most 128 multiplications. See this Wikipedia article for the details. In the end, the operation 5 ^ 128_bit_number should take a fraction of a second.
I am hacking around with IBPP on Visual Studio 2015 / VC++. IBPP is a c++ wrapper for the firebird / interbase API.
IBPP, a C++ Client Interface to Firebird Server
Part of this package is a little test-suite, you may download it here:
ibpp-2-5-3-1-src.zip
To start with the test-suite you will find a simple batchfile to compile it under
x:...\ibpp-2-5-3-1-src\tests\vs2005\simplest-build.bat
It compiles fine with the native x86 and x64 toolchains of vc++ 2015.
Before compiling you need to edit lines 84 to 86 of
x:...\ibpp-2-5-3-1-src\tests\tests.cpp
const char* DbName = "x:/ibpptest/test.fdb"; // FDB extension (GDB is hacked by Windows Me/XP "System Restore")
const char* BkName = "x:/ibpptest/test.fbk";
const std::string ServerName = ""; //"localhost"; // Change to "" for local protocol / embedded
Please keep mind to create the directory x:\ibpptest\.
Furthermore you need to download the fblient files which are not available on its own but as part of the entire server archive. Get these both files:
32-bit Embedded
and
64-bit Embedded
.
For simplifying create two directories besides x:\...\ibpp-2-5-3-1-src\tests\vs2005\:
x:\...\ibpp-2-5-3-1-src\tests\vs2015x86\
x:\...\ibpp-2-5-3-1-src\tests\vs2015x84\
and copy x:\...\ibpp-2-5-3-1-src\tests\vs2005\simplest-build.bat into them. Now copy the fbclient files (32 Bit to x86, 64 Bit to x64) in these directories:
intl/*
udf/*
fbembed.dll
firebird.msg
ib_util.dll
icudt30.dll
icuin30.dll
icuuc30.dll
msvcp80.dll
msvcr80.dll
Now you can compile and start tests.exe. The x86 binary generates some errors in Test 6, that's OK because you are using the embedded version of the fblient files. The x64 binary will end up in a Windows program failure screen. This happens in Test3 when the test suite activates an exception:
try
{
#if defined(IBPP_WINDOWS) && defined(_DEBUG)
OutputDebugString(_("An exception will now get logged in the debugger: this is expected.\n"));
#endif
st1->ExecuteImmediate( "CREATE SYNTAX ERROR(X, Y) AS "
"SELECT ERRONEOUS FROM MUSTFAIL M" );
}
catch(IBPP::SQLException& e)
{
//~ std::cout<< e.what();
if (e.EngineCode() != 335544569)
{
_Success = false;
printf(_("The error code returned by the engine during a\n"
"voluntary statement syntax error is unexpected.\n"));
}
}
In the x86 binary this exception was caught as expected but in the x64 binary it will not. Does anybody knows how to achive similar exception handeling in the x64 binary?
Thanks in advance for any help!
Caveat: I used the Visual Studio 2017 environment to run the simplest-build.bat file.
It appears from the evidence I provide below that there is a fork or other compiling difference between the 32 bit and 64 bit versions of the Firebird service that causes this problem.
Solution: The EngineCode() member function does not exist in the 64 bit version. You must use the exception's what() member function as shown in the commented out line inside the Test3() catch block. If you desire to use EngineCode information you will have to parse it out of the what() string, because that contains all of the information that was originally provided as individual data members in the IBPP::SQLExceptionImpl class for 32 bit.
try
{
#if defined(IBPP_WINDOWS) && defined(_DEBUG)
OutputDebugString(_("An exception will now get logged in the debugger: this is expected.\n"));
#endif
st1->ExecuteImmediate( "CREATE SYNTAX ERROR(X, Y) AS "
"SELECT ERRONEOUS FROM MUSTFAIL M" );
}
catch(IBPP::SQLException& e)
{
//~ std::cout<< e.what();
printf(e.what());
//if (e.EngineCode() != 335544569)
//{
// _Success = false;
// printf(_("The error code returned by the engine during a\n"
// "voluntary statement syntax error is unexpected.\n"));
//}
}
Result of what() call.
*** IBPP::SQLException ***
Context: Statement::ExecuteImmediate( CREATE SYNTAX ERROR(X, Y) AS SELECT ERRONEOUS FROM MUSTFAIL M )
Message: isc_dsql_execute_immediate failed
SQL Message : -104
can't format message 13:896 -- message file C:\WINDOWS\SYSTEM32\firebird.msg not found
Engine Code : 335544569
Engine Message :
Dynamic SQL Error
SQL error code = -104
Token unknown - line 1, column 8
SYNTAX
Puzzle: statement.cpp shows the use of IBPP::SQLExceptionImpl and other ...ExceptionImpl usage, so I have to believe this source code is the 32 bit branch. If this is supposed to be a common branch for both 32 and 64 bit, then I don't see how it can work.
There are two header files that define exception classes. I believe that _ibbp.h was used to compile the 32 bit client and ibbp.h was used for the 64 bit client. I came to these conclusions by changing the catch clause in Test3() to see what possible exceptions could be happening. The ...ExceptionImpl classes would only compile with the 32 bit client dlls and they would not compile with the 64 bit dlls.
From _ibpp.h (32bit fbclient dlls recognize these classes. 64bit fbclient dlls do not.)
///////////////////////////////////////////////////////////////////////////////
//
// Implementation of the "hidden" classes associated with their public
// counterparts. Their private data and methods can freely change without
// breaking the compatibility of the DLL. If they receive new public methods,
// and those methods are reflected in the public class, then the compatibility
// is broken.
//
///////////////////////////////////////////////////////////////////////////////
//
// Hidden implementation of Exception classes.
//
/*
std::exception
|
IBPP::Exception
/ \
/ \
IBPP::LogicException ExceptionBase IBPP::SQLException
| \ / | \ /
| LogicExceptionImpl | SQLExceptionImpl
| |
IBPP::WrongType |
\ |
IBPP::WrongTypeImpl
*/
From ibpp.h (both fbclient dll sets recognize these classes)
/* IBPP never return any error codes. It throws exceptions.
* On database engine reported errors, an IBPP::SQLException is thrown.
* In all other cases, IBPP throws IBPP::LogicException.
* Also note that the runtime and the language might also throw exceptions
* while executing some IBPP methods. A failing new operator will throw
* std::bad_alloc, IBPP does nothing to alter the standard behaviour.
*
* std::exception
* |
* IBPP::Exception
* / \
* IBPP::LogicException IBPP::SQLException
* |
* IBPP::WrongType
*/
In all of tests.cpp, the only catch for IBPP::SQLException is in Test3(). Every other catch uses IBPP::Exception.
So this problem will only show up in Test3() when compiling for 64 bit, but I think it would manifest itself whenever IBPP::SQLException is used in a 64 bit implementation.
After a lot of more research I found the cause. I was wrong beliving that the exception handling in x86 and x64 differ. The IBPP library contains a bug (since 10 years!) which only happens in the x64/windows szenario when the firebird library reports an (complex) error condition to the caller.
So what happens is:
The test programm calls the IBPP libarary. The IBPP library calls the firebird API / library. The firebird library reports its results of calls in a array[20] of longs, they call it "ISC_STATUS vector". The IBPP library checks this results and in a case of an error it throws an exception. The test program catches such exceptions and reports them to the use.
So far, so good. But the bug is, that IBPP defines ISC_STATUS as an array[20] of longs as firebird it also did until v2.0 - which only support x86 windows. Beginning with v2.1 firebird supports x64 windows an defines ISC_STATUS as an array of intptr_t which leads to "long long" on windows x64 LLP64 compilers and to long on LP64 linux compilers - both are 64 bit wide. On ILP32 windows and linux x86 compilers intptr_t is 32 bit wide.
IBPP doesn't closed the gap to firebird and stays on its definition of ISC_STATUS as long - which leads to a 32 bit wide data type on LLP64 windows x64 systems (but to 64 bit on linux, as gcc on linux uses a LP64 system, so the bug only happens on windows).
So the firebird x64 API reports up to 20 status integers to the "by reference parameter" array[20] of 64 Bit integers. The FBPP library passes an array[20] of 32 Bit integers. When the firebird API stores values in second half of the array it overwrites memory of the caller. In this case the next bytes after the ISC_STATUS vector are occupied by a c++ string object. Both, the status array and the string a part of the IBS (interbase status) class. Many of the IBPP functions often instantiating a local object of this class to manage the firebird API results and a error descriping string. When the functions exits the framework cleans up such local objects and tries to free the string but its metadata in memory was overwritten by the firebird API.
So the cleanup of the local IBS object leads to an unknown software exceptions which overdrives the exceptions thrown by the IBPP framework. And this exception is not catched by the test program but by windows / dr. watson.
I fixed the definition of ISC_STATUS from "long" to "intptr_t" and all works as expected.
Thank you all for your hints.
I red the following article and it seems like I should be able to define a variable of type varying that's size limit will be 16mb instead of 65535 characters.
http://www.mcpressonline.com/programming/rpg/v6r1-rpg-enhancements.html
This forum post suggests that it is posible to do this in V6.1.
http://www.code400.com/forum/forum/iseries-programming-languages/rpg-rpgle/11426-character-string-max-length
D BigVarying S a Len(25000000) Varying(4)
When I try to implement this I get the following errors and it seems like I cannot use Len(25000000) Varying(4)
Maybe I don't understand what exactly is meant by V6.1 but I checked on the Green screen using the command DSPSFWRSC and get the following Release V6R1..
I also checked by using I systems navigator and I checked the servers properties and it is : i5/OS version Version 6 Release 1 Modification 0.
The IDE I use to compile is IBM Websphere development studio
Version: 7.0.0
Build id: 20070202_0030
Trying to compile a RPGLE function.
Am I checking the correct version or is there a RPG version and how do you check it.
can you please help me out of my confusion.
V6.1 is your operating system version and you can refer to the V6.1 ILE RPG Language Reference here to see if it's possible. I think what you're looking for is on page 185.
I've just tested this in 7.2 and I am not getting the same errors.
D BigVarying S a Len(25000000) Varying(4)
RNF0501E Length of character item exceeds 16773104; length defaults to 16773104.
RNF0231E Length of varying length character item exceeds 16773100; length defaults to 16773100.
//Dcl-S BigVarying Varchar(25000000);
BigVarying = 'Hello world';
Return;
So, as the (duplicate) error mentions
Length of character item exceeds 16773104; length defaults to 16773104.
If you'd like a bigger length you'll need to update to a newer version of IBM i - but the max length is also 16773104, meaning 25000000 is invalid.
While RPGLE supports 16MB variables from 6.1 forward and you are on 6.1..
You have two problems:
25000000 (23.8MB) is bigger than 16773104 (~16MB)
Websphere Development Studio v7 (WDSc) is older than IBM i 6.1 (your build date is 2007, the article you're referencing came out in 2008). So your IDE doesn't recognize the new keywords and new max size.
Problem #2 isn't a deal breaker, you can simply ignore the errors in the IDE and compile on ther server successfully. If you were using the green screen editor SEU, you'd have to do the same as IBM stopped enhancing SEU at 6.1.
Using the code below sometimes the text variable contains a very huge and strange number, something like "1552505576255083400000000000000000000000000000000000000000000000000000.000".
A "0.000" string is expected.
I've also tryed with a basic dialog app and execute these two lines of code in the "OnInitDialog()"
I'm using VS 2013. With VS 2003 seems that it works correctly.
can somebody tell me why?
CString text;
text.Format(_T("%.3f"), 0);
Your code has a bug. The %f format specifies requires a floating point number and you specify an integer. To fix the bug, change the 0 to 0.0.
This is a problem on spoj.com (http://www.spoj.com/problems/PRIC/) .We have to check whether numbers of the sequence : ai=( a(i-1)+1234567890 ) mod 2^31 are prime or not, 1st number is 1.
My code is given below (Please try to ignore the clumsiness.) based on sieve of eratosthenes .
The PROBLEM : We have to print "prime(1) or not(0)" for sequence upto i=33,333,333 , My code works perfectly fine for i( c3 in the code) values upto 8000 or so and after that (e.g c3>19000 ) it starts giving The SIGFPE error . Now i googled about the error , it has something to do with division/ mod by 0. But why is it that code works for c3 values upto 9000 but not beyond that?
Depending on your compiler and development environment, you should read up on the concept of a Debugger. This answer has a guide to use gdb. If you are using Visual Studio, Code::Blocks or any other IDE, look up the debugging features. For instance how to set a breakpoint or step into/out of/over a function call for instance, watching or changing variables etc. (I'm mentioning these things to give you vital hints for Google search-words, wink wink nudge nudge).
EDIT:
Copy-pasted the code and saved it, compiled with gcc -g for debug symbols and -lm to link the math library, I ran it through gdb and it gave me this output:
Program received signal SIGFPE, Arithmetic exception.
0x0000000000400707 in sieve (prime=0x6626a0) at t.c:43
43 if (a%prime2[j]==0){
This tells you to look at line 43, at the if statement that uses a modulo operation. This seems to be the place you are doing the modulo zero.
Do note that line 43 in the document I got when I copy-pasted your code from Stackoverflow, may not be line 43 in your document.
EDIT2:
Hey my answer was unaccepted! - why was that :) ?