Re: problem with memcpy and pointers/arrays confusion - again

Barry Schwarz wrote:
On Sat, 11 Mar 2006 12:42:13 +0100, Martin Jørgensen
<unoder.spam@xxxxxxxxxxxx> wrote:


#include <stdio.h>
#include <stdlib.h>

int main()
{
unsigned long int total_mem_used = 0; // counter
int N = 20; // whatever number of elements

int *int_array = allocate_mem((N+1)*sizeof(int), __FILE__, __LINE__, &total_mem);


There is no prototype in scope for allocate_mem. The compiler is
forced to assume it returns int. Error 1 is it doesn't so you invoke
undefined behavior. Error 2 is there is no implied conversion between
the assumed return type of int and the pointer on the left of the =
sign. Error 3 is you apparently chose to ignore the warning this
assignment generated. While you are free to ignore warnings (just as

Error 3: I can't ignore anything I didn't see yet.

compilers are free to produce meaningless ones), you really should
know why you are ignoring it before you decide to do so.

As I wrote, that code was/is untested. I didn't/I don't expect people to copy/paste something that is "untested" into their compiler, just to look at the code and provide some comments so I can implement it myself.

I can however see that Michael is doing a great job and helping me out with good suggestions. That is actually more than I hoped for, so ofcourse I have no problem with that (on the contrary I higly appreciate the help I get here).

printf("int_array takes up: %i bytes in memory", *int_array[N]);


[] has higher precedence than *. The expression is parsed as
*(int_array[N]). int_array is a pointer to int. int_array[N] is the

Ok.

N-th int after the first (which would be int_array[0]). It is not
legal to apply the dereference operator to an int. Why did you ignore
this diagnostic?

I didn't ignore it because I haven't seen it. I've had a cold this weekend and is still a bit ill...

double *double_array = allocate_mem((N+1)*sizeof(double), __FILE__, __LINE__, &total_mem);
printf("double_array takes up: %i bytes in memory", *double_array[N]);


double_array is a pointer to double. Once you fix the conflict
between the [] and * operators as noted above, the second argument
will end up a double. But your %i tells printf to expect an int. Lie
to the compiler and invoke undefined behavior.

Yes. That was a mistake. I thought of saving the memory occupation as integer (should actually be size_t, as Michael proposes). But that is probably a bit more complicated when dealing with double *-arrays, as I can see Michael Mair also discusses.

printf("Total memory occupation is: %li bytes", *total_mem);

free(int_array);
free(double_array);

exit(0);
}


void *allocate_mem(size_t size, char *file, int line, *total_mem)
{
int *void_ptr = malloc(size);
if (void_ptr == NULL)
{
fprintf(stderr, "%s: line %d, malloc(%ld) failed.\n", file, line, size);
exit(EXIT_FAILURE);
}

void_ptr[N] = size; // save memory allocated for this pointer


On the second call, you allocate space for N+1 doubles. But since
void_ptr is an int*, on systems where doubles are 8 and ints are 4
bytes, you are not storing data in the last double. Furthermore,

Yeah, having void_ptr an int* is completely wrong if it should be universal for all pointer types. Not sure I got that part about not storing data in the last double, though...

As I see it (which is probably wrong) I would perhaps not be storing data in the last int, but size_t size would still be written to the last element in void_ptr???

storing an int bit pattern in a double could possibly generate a trap
representation. Furthermore, it would only initialize half the
double, the other half is still indeterminate. Back in main, when you

I understand that it would only initialize half of the double, but that's not a big problem is it?

try to print the N-th double, you invoke undefined behavior by
evaluating an uninitialized variable.

Actually I think I'll start with the code Michael provided... This code was an early "pre-alpha-version" and Michael came with some better suggestions so it's clearly a better idea to start with them...


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk
.

Relevant Pages

  • Re: [PATCH 3/7] PCI PM: Fix saving of device state in pci_legacy_suspend
    ... so the icache is going to scream but gcc folks know ... I'll see Michael what exactly the situation is here and if we ... int smp_request_message_ipi ...
    (Linux-Kernel)
  • Re: Simple question about dllimport
    ... Michael C wrote: ... deviceNumber, int *pHandle); ...
    (microsoft.public.vc.language)
  • Re: Swapping
    ... In comp.lang.c Julie wrote: ... > Michael wrote: ... >> Dan you need to try stuff for yourself ... >> int main{ ...
    (comp.lang.cpp)
  • Re: bug in glibc?
    ... no, consider the source incorrect: ... int main ...
    (comp.os.linux.misc)
  • Re: Swapping
    ... In comp.lang.c Julie wrote: ... > Michael wrote: ... >> Dan you need to try stuff for yourself ... >> int main{ ...
    (comp.lang.c)
Loading