To start with you should compile with debugging symbols enabled, so that the backtrace tells you where the error happens (or at least where the error is first detected). The next step would be to run your code in a debugger to see what's going on when (and before) the error occurs.

shurd, on 25 May 2013 - 12:57 PM, said:

This won't work. aux is uninitialized and passing it to strcpy will invoke undefined behavior. In practicaly terms, this will cause strcpy to try to copy the string into "random" memory, which might cause a segmentation fault or other undesired consequences.

You could make this work if you allocate the memory for aux on the heap using malloc, but then you'd need to free it when you're done with it. This will make your code more complicated (instead of just doing printf("%s", get_bla(fix)); you'd need char * bla = get_bla(fix); printf("%s", bla); free(bla);), will introduce the possibility of a memory leak if the user of the get_ function isn't careful and it would just be a waste of time and space since you don't actually need or want to create a copy of the string.

Quote

Consider this:

int main()
{
    struct tipo_Fix fix1;
    struct tipo_Fix fix2;
    set_Fix_chavePrimaria(&fix1,"ID28");
    set_Fix_chavePrimaria(&fix2,"ID29");
    char * cp1 = get_Fix_chavePrimaria(fix1);
    char * cp2 = get_Fix_chavePrimaria(fix2);
    printf("%s", cp1);
    printf("%s", cp2);
    return 0;
}

What will the output of this code be using the above definition of get_Fix_chavePrimaria? Is that the output you'd want to get?

The only way to make a get function work sensibly in this case would be to have it take a pointer to the struct.

Quote

If the definition of the struct is visible to the user, I see no point in having a get function as the user can just access the field's directly anyway. If you want the definition of your struct to be hidden from the user, it would make sense to have a get function. And since, in that case, the get function would have to take a pointer anyway, that'd work out fine.

ccubed, on 16 May 2013 - 01:55 PM, said:

The code does (and should) compile just fine. It is perfectly valid to pass 0 to a function expecting a pointer - that will simply call the function with a null pointer. Of course those functions shouldn't be called with null pointers as arguments, but the compiler doesn't know that.

You're calling scanf with a null pointer as an argument, which invokes undefined behavior. You're also passing a null pointer to CalculateVolume and then dereferencing it, again invoking undefined behavior. Further it doesn't make sense that a function that's supposed to calculate a volume would take that volume as a non-pointer argument. Assigning to Volume within CalculateVolume won't have any effect. You're also not using the return value of CalculateVolume.

If you make the arguments ArrayList<Object>, you won't be able to pass ArrayList<String> or anything else to the method (generics in Java are not covariant if used without wild cards). Making both arguments ArrayList<?> would work, but so would the OP's solution as far as I can tell (though the body of the method could definitely do with some cleaning up -- like removing the pointless inner loop).