I am using Windows 7 and have a 64 bit and a 32 bit version of my program. The 32 bit version works perfectly fine, however, I am having issues with the 64 bit version at runtime. I have a list view item created and am filling the columns with my information. All of them are printing, but one is not printing correctly. This is what it is printing (I apologize for the lack of a picture but as a new member I am unable to post pictures):
Truck
ÍÍÍÍHRZ141
ÍÍÍÍHRZ152
It seems to be placing 4 null characters before the information I actually want it to display. Upon further examination, it appears as though the addressing is incorrect. Here is a section of my code where the error is occurring:
Audit * audit = (Audit *)plvdi->item.lParam;
switch(plvdi->item.iSubItem)
{
case 0:
{
plvdi->item.pszText = audit->Truck;
while(plvdi->item.pszText[0] != 'H')
{
plvdi->item.pszText++;
}
}
return true;
This is a temporary fix due to the fact that all of my truck names start with the character H. plvdi->item.psz text is the text display of the list view item, and audit->Truck is a char[]. It should be as simple as:
sprintf(plvdi->item.pszText, audit->Truck);
but that doesn't seem to work. It leaves me with the same error. When run, the address plvdi->item.pszText is 4 bytes less than the address of audit->Truck, after the assignment statement (breakpoint on the while statement), which I believe is causing the 4 null characters. I am just unsure as to how to resolve this problem without a work around such as the one I posted, why this is happening, and why only in the 64 bit solution. Thank you in advance for any help on this matter.
EDIT: From other similar problems I have found within my program, it seems to have something to do with pointers. Everything in my Audit class that came after a selections vector was having problems and appeared to be off by 4 bytes. In another class, I found that everything coming after a pointer to an Audit failed and I also had some issues with strings (which are technically pointers to char arrays). When I moved the elements with pointers to the end of the class in the header file, everything seemed to work fine again. Any idea if strings, vectors, or other similar structures have pointers that are dependent upon 32 or 64 bit systems?
On 64 bit windows platform, sizeof of a pointer is 8 bytes, while is 4 on a 32 bit configuration. Check your code to avoid the 4 bytes size assumption.
Related
I'm experiencing a perculiar issue when using sprintf.
I need a char array to look like this: g;cmd;arg;e;, where arg gets leading zeros so it is always 3 chars long, and cmd gets leading zeros so it's always 15 chars long.
As an example, if cmd = 20 and arg = 3749, I need a char array looking like this: g;020;000000000003749;e;.
Both arg and cmd are integers.
I initially accomplished this in pretty inefficient way, but I changed it to something much simpler using sprintf because I needed my code to be faster. Both my initial code and my change can be found on github.
My current implementation looks like this:
#define cmdMsgLength 3
#define argMsgLength 15
#define totalFormatedMsgLength (2+cmdMsgLength+1+argMsgLength+3)
#define msgFormater "g;%03d;%015d;e;"
char msgToSendFormated[totalFormatedMsgLength];
void sendMsg(int _cmd, int _arg) {
sprintf(msgToSendFormated, msgFormater, _cmd, _arg);
Serial.print(msgToSendFormated);
}
This seemed to work well, until my uC also had to control 4 ESC's. I honestly can't find any relation between the two, but it seems like this implementation leads to problems with the ESC's, where of course timing is quite important. The ESC's are being programmed correctly, but when using the Arduino function servo.writeMicroseconds to actuate them, they seem to act randomly. After quite a lot of tests, only this change to my code seems to be causing the issue. As this piece code is so simple and the old code (check the github link) also used Serial.print, I assume sprintf is the culprit.
Is sprintf known to cause these sort of timing-issues? Could it be anything else?
As JVApen pointed out, sprintf always writes a null terminator. As msgToSendFormated was not long enough for that, I'd get an overflow. Setting char msgToSendFormated[totalFormatedMsgLength + 1]; fixed the problem.
I am a beginner to programming. I am trying to run a simulation of a combustion chamber using reactingFoam.
I have modified the counterflow2D tutorial.
For those who maybe don't know OpenFOAM, it is a programme built in C++ but it does not require C++ programming, just well-defining the variables in the files needed.
In one of my first tries I have made a very simple model but since I wanted to check it very well I set it to 60 seconds with a 1e-6 timestep.
My computer is not very powerful so it took me for a day aprox. (by this I mean I'd like to find a solution rather than repeating the simulation).
I executed the solver reactingFOAM using 4 processors in parallel using
mpirun -np 4 reactingFOAM -parallel > log
The log does not show any evidence of error.
The problem is that when I use reconstructPar it works perfectly but then I try to watch the results with paraFoam and this error is shown:
From function bool Foam::IOobject::readHeader(Foam::Istream&)
in file db/IOobject/IOobjectReadHeader.C at line 88
Reading "mypath/constant/reactions" at line 1
First token could not be read or is not the keyword 'FoamFile'
I have read that maybe some files are empty when they are not supposed to be so, but I have not found that problem.
My 'reactions' file have not been modified from the tutorial and has always worked.
edit:
Sorry for the vague question. I have modified it a bit.
A typical OpenFOAM dictionary file always contains a Foam::Istream named FoamFile. An example from a typical system/controlDict file can be seen below:
FoamFile
{
version 2.0;
format ascii;
class dictionary;
location "system";
object controlDict;
}
During the construction of the dictionary header, if this Istream is absent, OpenFOAM ceases its operation by raising an error message that you have experienced:
First token could not be read or is not the keyword 'FoamFile'
The benefit of the header is possibly to contribute OpenFOAM's abstraction mechanisms, which would be difficult otherwise.
As mentioned in the comments, adding the header entity almost always solves this problem.
In my code, I found one qDebug()<<s; didn't output the content given to it. It's very strange, so I output s.length(). It says 135254, so I'm wondering whether there is a limitation of length which is shorter than 135254? I have read the source header and do not find the result.
i noticed something similar...
This might narrow it down a bit (using Qt 5.5.1 with Windows mingw):
45000 character trace did not show up in qDebug.
10000 character trace did show up in qDebug.
I was able to qDebug my 45000 characters as 5 separate qDebug calls, each was something like this:
qDebug()<<foo.mid(20000, 10000);
then piece them together in a text editor.
it may have been a little nicer to use qDebug's noQuotes feature too, but i don't need to run my script again today so I'm not prettying it up right now.
In an effort to better understand RSA I've been fooling around with the source code for GunPG 1.4, specifically the RSA implementation in the rsa.c file. As the title says, I can't figure out where the padding is happening.
So typically in RSA, padding is done right before the encryption and is taken off during the decryption. Encryption first starts around line 409 where we see
int
rsa_encrypt( int algo, MPI *resarr, MPI data, MPI *pkey )
{
RSA_public_key pk;
if( algo != 1 && algo != 2 )
return G10ERR_PUBKEY_ALGO;
pk.n = pkey[0];
pk.e = pkey[1];
resarr[0] = mpi_alloc( mpi_get_nlimbs( pk.n ) );
public( resarr[0], data, &pk );
return 0;
}
That seems easy, it's giving data to "public" function higher up on line 220. Public is responsible for calculating the important (c = m^e mod n) process. That all looks like:
static void
public(MPI output, MPI input, RSA_public_key *pkey )
{
if( output == input ) { /* powm doesn't like output and input the same */
MPI x = mpi_alloc( mpi_get_nlimbs(input)*2 );
mpi_powm( x, input, pkey->e, pkey->n );
mpi_set(output, x);
mpi_free(x);
}
else
mpi_powm( output, input, pkey->e, pkey->n );
}
Wait a second...now it looks like public is passing the job of that calculation off to mpi_powm() located in the mpi-pow.c file. I'll spare you the details but that function gets really long.
Somewhere in all of this some sort of PKCS#1 padding and unpadding (or something similar) is happening but I can't figure out where for the life of me. Can anyone help me see where the padding happens?
In an effort to better understand RSA I've been fooling around with the source code for GnuPG 1.4, specifically the RSA implementation in the rsa.c file.
Since you’re looking at the older (< 2.0) stuff anyway, and since it’s only for learning purposes, I would rather advise you to check out “ye olde rsaref.c from gnupg.org” where the padding is implemented in a pretty obvious way.
… some sort of PKCS#1…
To be exact, GnuPG uses PKCS #1 v1.5 (specified in RFC 4880).
Can anyone help me see where the padding happens?
Hmmm, let’s see if I can wrap that up somewhat logically. GnuGP pads according to PKCS #1 v1.5, so it just adds random pad to satisfy length requirements.
If you take a look at the cipher/pubkey.c file (which includes the rsa.h file in its head), you’ll notice a pubkey_table_s struct which defines a list of elements that define the key. For padding reasons, random bytes are appended to that list (better: after that struct). It’s done that way because those random bytes can easily be stripped by looking for the end of the list. Keeping a long story short, that’s where random.c probably starts to make a bit more sense to you. Now, all that stuff (and a whole lot more) is compiled into a lib called libcipher… which in itself is compiled to be used by functions that add the padding and handle the RSA stuff the way you expected it. In the end, the compiled executables use the functions libcipher provides to take care of the padding – depending on the individual need for padding.
So what you currently expect to find in 1 or 2, maybe 3 files is actually spread out across more than half a dozen files… which I regard not to be the best base for your learning efforts. As said, for reference purposes, I’ld go for the old rsaref.c they once started out with.
Not sure if this actually provides all the details you wanted to get, but it should give you a first good heads-up… hope it helps.
GPG 1.4 doesn't use any padding at all. It encrypts the raw session key.
Good day. The programs function is to take an equipment number (or none), display that number with a description (or all) in alv, and then run IE03 should the user double click on
Program worked fine in client 110, but in 150 a runtime error happens. This morning I tried to make a new program with a shorter name (only lead I had), activated it (window popped up asking me to activate the previous version as well). That didn't work and now the original doesn't work in either.
The program "SAPLSKBH" is terminating because program line is too long, being 78 chars wide which is too much for the internal table "\FUNCTION=K_KKB_FIELDCAT_MERGE\DATA=L_ABAP_SOURCE[]"
It sounds like you are using REUSE_ALV_GRID_DISPLAY for output, is that correct?
Check you source code; somewhere you have a line that is more than 78 characters. The function K_KKB_FIELDCAT_MERGE takes the source code of your program to produce a structure that corresponds to the table/structure you give it. (In the old days, there was a limit of 78 characters width for a line of ABAP code, and this is an old function module).
You can alternatively build a field catalog yourself in code, rather than use this function.