strange segmentation fault

[Dan Feerst]

I'm working on a small project which requires some bitwise manipulation
basicly in this snippet of code I am using calloc to create a null space of a certain length and write argv[1] to the beginning of it. There is more obviously but I have a strange problem. I get segmentation faults if argv[1] is >6 bytes, or 48 bits. What is really strange is that the segmentation fault happens after the program runs and if I pipe the output to hexdump, it seem to be doing what I want it to. Any ideas?

#include <cstdlib>
#include <iostream>
#include <cstring>
#include <cassert>
#include <cmath>
typedef unsigned int bitsize_t;
typedef unsigned int bytesize_t;
using namespace std;
int main(int argc, char** argv)
{
    	assert(argv[1] != NULL );
    	char* padding;
    	bytesize_t M = strlen(argv[1]);
		bitsize_t l = 8 * M;
		float blocks = ceil(( (float)l + 1. + 64. ) / 512 );
		cout << "Allocating "<< blocks * 512 /8 << " bytes\n";
		padding = (char*)calloc( (512 * blocks) / 8, sizeof(char));
		cout << "empty set padding -->"<<padding<<"<--"<<endl;
		memcpy(&padding,&argv[1],l);
        cout << "padding -->"<<padding<<"<--"<<endl;
}

[ne555]

man wrote:

void *memcpy(void *dest, const void *src, size_t n);
The memcpy() function copies n bytes from memory area src to memory area dest.

    	bytesize_t M = strlen(argv[1]);
	bitsize_t l = 8 * M;
	memcpy(&padding,&argv[1],l); //¿? 

`argv[1] has length `M', no `l'

[Dan Feerst]

Wow. I'm dumb. Thanks.

[Dan Feerst]

Still having very strange problems.
M = 1 to 2, I don't get segmentation faults but it doesn't copy anything
M = 3 -5 , it doesn't copy and I get segmentation faults
M= 6-48, works correctly
M= 49-?, copies data but I get segmentation faults.

#include <cstdlib>
#include <iostream>
#include <cstring>
#include <cassert>
#include <cmath>
typedef unsigned int bitsize_t;
typedef unsigned int bytesize_t;
using namespace std;
int main(int argc, char** argv)
{
    	assert(argv[1] != NULL );
    	char* padding;
    	bytesize_t M = strlen(argv[1]);
	bitsize_t l = 8 * M;
	float blocks = ceil(( (float)l + 1. + 64. ) / 512 );
	padding = (char*)calloc(512 * blocks/ 8, sizeof(char));
	memcpy(&padding,&argv[1],M);
        return 0;
}

[cire]

memcpy(padding, argv[1], M);

&padding is the address of the pointer that is allocated on the stack. &argv[1] is the address/offset of the parameter that is, likewise, on the stack. You were reading from and writing to memory you have no business accessing.

[Dan Feerst]

ummmm..... Thanks, I think. Now that you clarified that, what if I wanted to write a program which among other things was able to copy bitwise from the command arguments to a location of a predetermined size which I have business accessing?

[cire]

You can't copy anything "bitwise." Everything is done at the granularity of bytes when you get to moving things around. You can, of course, manipulate the bits in a byte, but that doesn't seem to have any relation to what you are doing. You are simply moving bytes around.

See the line of code in the post I made and note how it differs from the analogous line in yours.

It is unclear to me what you're attempting to accomplish with the calculations on lines 14-16. Presumably there is some other aspect to the code that isn't show here.

[Dan Feerst]

I'm attempting to write a SHA 256 algorithim, as defined in FIPS PUB 180-4. Strictly for pedigogical purposes. It seemed like a difficult project, however one that would help me learn lower level movement of information. Basiclly what I have to do is create an array of data which has a length with a multiple of 512 bits. The first bytes will be the message itself, followed by a bitwise 1 then padded with zeros until the last 64 bits which is the length of the message.

When I remove the reference operators it appears to be working as desired, however I am still trying to figure out why they would be use in the first place.

[cire]

The ampersand used here is more commonly called the "address of" operator. Although I've seen it called a "reference" operator in some naive tutorials, that really is something I think should be avoided. & used as an operator has nothing to do with the C++ concept of references.

The standard supports this obliquely. There is no entry in the index for operator, reference but there is for operator, address-of.