I made a function for adding next numbers in the array. Code is very simple, like following
int math(int *address, int size)
{
int sum = 0;
for (int i = 0; i < size; i++)
{
sum += *address;
address++;
}
return sum;
}
During static analysis I found, that there is problem against MISRA rule - which is saying that you can do math only on pointers assigned to an array. Purpose of this function is to use it on arrays, but of course - what I wrote in here is not guarantee that pointer won't be assigned to a variable.
One work-around which I think about is to copy whole table to local area and then sum all elements, but it's rather big operation, wasting lot of uprocessors assets. Do you have any ideas how can I make it better?
This would be from MISRA-C:2004 chapter 17, which was rather irrational about the use of pointers and arrays. This chapter was rewritten from scratch in MISRA-C:2012 (chapter 18). I would strongly recommend to upgrade, since MISRA-C:2004 simply doesn't make much sense here.
As for how to make your code MISRA-C:2004 compliant, do this:
int math(int address[], int size)
{
int sum = 0;
int i; // declaration must be here, MISRA-C:2004 does not allow C99
for (i = 0; i < size; i++)
{
sum += address[i];
}
return sum;
}
Yes it does the very same thing. But at least it made your code slightly more readable.
To make your code even safer, although not compliant with any MISRA, do this:
// better than MISRA-C but not compliant
int math(size_t size, int address[size])
{
int sum = 0;
for (size_t i = 0; i < size; i++)
{
sum += address[i];
}
return sum;
}
Or in case of high integrity systems, you could even do:
int math(size_t size, int (*array)[size])
{
int* address = *array;
...
Both of these alternatives give safer code than MISRA-C.
Related
I have a function in C which calculates the mean of an array. Within the same loop, I am creating an array of t values. My current function returns the mean value. How can I modify this to return the t array also?
/* function returning the mean of an array */
double getMean(int arr[], int size) {
int i;
printf("\n");
float mean;
double sum = 0;
float t[size];/* this is static allocation */
for (i = 0; i < size; ++i) {
sum += arr[i];
t[i] = 10.5*(i) / (128.0 - 1.0);
//printf("%f\n",t[i]);
}
mean = sum/size;
return mean;
}
Thoughts:
Do I need to define a struct within the function? Does this work for type scalar and type array? Is there a cleaner way of doing this?
You can return only 1 object in a C function. So, if you can't choose, you'll have to make a structure to return your 2 values, something like :
typedef struct X{
double mean;
double *newArray;
} X;
BUT, in your case, you'll also need to dynamically allocate the t by using malloc otherwise, the returned array will be lost in stack.
Another way, would be to let the caller allocate the new array, and pass it to you as a pointer, this way, you will still return only the mean, and fill the given array with your computed values.
The most common approach for something like this is letting the caller provide storage for the values you want to return. You could just make t another parameter to your function for that:
double getMean(double *t, const int *arr, size_t size) {
double sum = 0;
for (size_t i = 0; i < size; ++i) {
sum += arr[i];
t[i] = 10.5*(i) / (128.0 - 1.0);
}
return sum/size;
}
This snippet also improves on some other aspects:
Don't use float, especially not when you intend to return a double. float has very poor precision
Use size_t for object sizes. While int often works, size_t is guaranteed to hold any possible object size and is the safe choice
Don't mix output in functions calculating something (just a stylistic advice)
Declare variables close to where they are used first (another stylistic advice)
This is somewhat opinionated, but I changed your signature to make it explicit the function is passed pointers to arrays, not arrays. It's impossible to pass an array in C, therefore a parameter with an array type is automatically adjusted to the corresponding pointer type anyways.
As you don't intend to modify what arr points to, make it explicit by adding a const. This helps for example the compiler to catch errors if you accidentally attempt to modify this array.
You would call this code e.g. like this:
int numbers[] = {1, 2, 3, 4, 5};
double foo[5];
double mean = getMean(foo, numbers, 5);
instead of the magic number 5, you could write e.g. sizeof numbers / sizeof *numbers.
Another approach is to dynamically allocate the array with malloc() inside your function, but this requires the caller to free() it later. Which approach is more suitable depends on the rest of your program.
Following the advice suggested by #FelixPalmen is probably the best choice. But, if there is a maximum array size that can be expected, it is also possible to wrap arrays in a struct, without needing dynamic allocation. This allows code to create new structs without the need for deallocation.
A mean_array structure can be created in the get_mean() function, assigned the correct values, and returned to the calling function. The calling function only needs to provide a mean_array structure to receive the returned value.
#include <stdio.h>
#include <assert.h>
#define MAX_ARR 100
struct mean_array {
double mean;
double array[MAX_ARR];
size_t num_elems;
};
struct mean_array get_mean(int arr[], size_t arr_sz);
int main(void)
{
int my_arr[] = { 1, 2, 3, 4, 5 };
struct mean_array result = get_mean(my_arr, sizeof my_arr / sizeof *my_arr);
printf("mean: %f\n", result.mean);
for (size_t i = 0; i < result.num_elems; i++) {
printf("%8.5f", result.array[i]);
}
putchar('\n');
return 0;
}
struct mean_array get_mean(int arr[], size_t arr_sz)
{
assert(arr_sz <= MAX_ARR);
struct mean_array res = { .num_elems = arr_sz };
double sum = 0;
for (size_t i = 0; i < arr_sz; i++) {
sum += arr[i];
res.array[i] = 10.5 * i / (128.0 - 1.0);
}
res.mean = sum / arr_sz;
return res;
}
Program output:
mean: 3.000000
0.00000 0.08268 0.16535 0.24803 0.33071
In answer to a couple of questions asked by OP in the comments:
size_t is the correct type to use for array indices, since it is guaranteed to be able to hold any array index. You can often get away with int instead; be careful with this, though, since accessing, or even forming a pointer to, the location one before the first element of an array leads to undefined behavior. In general, array indices should be non-negative. Further, size_t may be a wider type than int in some implementations; size_t is guaranteed to hold any array index, but there is no such guarantee for int.
Concerning the for loop syntax used here, e.g., for (size_t i = 0; i < sz; i++) {}: here i is declared with loop scope. That is, the lifetime of i ends when the loop body is exited. This has been possible since C99. It is good practice to limit variable scopes when possible. I default to this so that I must actively choose to make loop variables available outside of loop bodies.
If the loop-scoped variables or size_t types are causing compilation errors, I suspect that you may be compiling in C89 mode. Both of these features were introduced in C99.If you are using gcc, older versions (for example, gcc 4.x, I believe) default to C89. You can compile with gcc -std=c99 or gcc -std=c11 to use a more recent language standard. I would recommend at least enabling warnings with: gcc -std=c99 -Wall -Wextra to catch many problems at compilation time. If you are working in Windows, you may also have similar difficulties. As I understand it, MSVC is C89 compliant, but has limited support for later C language standards.
I heard from a programmer (actually an IT teacher) that I should never write this:
void foo(bool foobar) {
if(foobar) {
size_t i;
for (i = 0; i < 42; i++) {
// Do something
}
}
}
But this:
void foo(bool foobar) {
size_t i;
if(foobar) {
for (i = 0; i < 42; i++) {
// Do something
}
}
}
Why?
Moreover, it seems that size_t is also bad because using a unsigned value prevent the compiler to do a good optimization.
That's nonsense. Always reduce the scope of variables as much as possible.
As for performance, it doesn't matter in the slightest. Since a local variable has automatic storage, the compiler will stack your variable just before it is used, no matter where the declaration appears in the source code.
That size_t would prevent the compiler from effectively optimizing your code is also nonsense.
Now what you should do, for scope and style reasons:
for (size_t i = 0; i < 42; i++)
And if this doesn't compile, you need to upgrade to a compiler which isn't older than 15 years.
It is only about subjective matter of coding style. The both codes compiles equally to the same behaviour. One may preffer:
void foo(bool foobar) {
size_t i;
if (foobar) {
for (i = 0; i < 42; i++) {
// Do something
}
}
}
as variable declaration is listed at the top. The second school is to declare variable closest to its usage (this code is perfectly valid in C89), so:
void foo(bool foobar) {
if (foobar) {
size_t i;
for (i = 0; i < 42; i++) {
// Do something
}
}
}
can be preferred instead. Using a C99/C11 compiler it would be even to better to declare it directly in the for loop:
void foo(bool foobar) {
if (foobar) {
for (size_t i = 0; i < 42; i++) {
// Do something
}
}
}
Old-style C (K&R) required all auto variables (in the old sense) to be declared at the beginning of the function after the part that set out the parameter types.
Newer standards (ANSI C) relax that, and modern coding conventions prefer keeping the scope of variables as tight as possible as that increases program stability.
I'd go one stage further and write (possible since C99)
for (size_t i = 0; i < 42; i++)
as then the scope of i is limited to the for loop: there's no danger it will be relied upon in error in other parts of your program.
As for using size_t as the counter, I can't see why that would constrain a compiler's optimisation strategy. In fact, I'd suspect that < could be faster on unsigned types since you don't need to handle a sign bit.
I have a structure that I pass to a function as constant pointer, my question is the following: There is a difference between those two implementations of function updatedFields:
typedef struct
{
int spec[100];
int spec1[200];
int spec2[200];
int spec3[500];
int spec4[100];
int spec5[700];
float value[100];
char desc[1000]:
}t_product;
void updateFields_1(t_product const* context)
{
int i,buffer[1500];
int * pt_int;
pt_int = (int*)context->spec1;
for(i = 0; i < 200; i++)
{
buffer[i] = pt_int[i];
}
pt_int = (int*)context->spec3;
for(i = 0; i < 500; i++)
{
buffer[i] = pt_int[i];
}
...
}
void updateFields_2(t_product const* context)
{
int i,buffer[1500];
for(i = 0; i < 200; i++)
{
buffer[i] = context->spec1[i];
}
for(i = 0; i < 500; i++)
{
buffer[i] = context->spec3[i];
}
...
}
int main(void)
{
t_product prod;
/* Initialisation of the structure */
...
updateField(&prod);
}
I mean, there is any advantages to use pointer to member of a struct (pointer to the arrays) instead of accessing directly to the member of struture.
It's probably a dumb question but I don't know if the access of a struct member "costs" more operations.
It won't ever cost more in your case. Even without optimization. Actually your pt_int example is likely to be slightly worse if you don't enable optimizations.
This is because context->spec3[i] isn't dereferencing more pointers than pt_int[i]. pt_int[i] is just a pointer plus an offset, so the access can be written as #(ptr_int + 4*i). In context->spec3[i], it could look like there is one more pointer dereferenced, but it isn't the case. spec3 isn't a value in context, it's just an offset from context. The address you access will therefore be #(context + 2000 + 4*i). There is only one pointer access.
Now you can wonder if #(context + 2000 + 4*i) costs more than #(ptr_int + 4*i). It doesn't, because most architectures, including x86, AMD64 and ARM (that is, 100% of personal devices), have instructions to do accesses with constant offsets. Also, the difference can disappear at soon as you enable trivial optimizations, because context + 2000 can be converted to a single context_2000 (but compilers won't actually do that, since it can only worsen performances).
It does cost more (it has to de-reference the original pointer each iteration), but the cost is probably small, and a halfway decent compiler will make this optimization for you.
Ok, I understand that my title might be a bit confusing, but I'll explain. I'm working on a homework assignment in C. I'm given a .c file and need to come up with implementations for some functions.
In short, I have this as a .c file
typedef int set_t;
...
void init(set_t *a, int N); // Initialized an array to a of size N
...
int main() {
set_t a;
init(&a, 10);
}
In a couple of implementations I've come up with, I was able to create an array using a, but I keep getting segmentation faults when the program runs :-/. Is there away to initialize a as an array without changing anything in the original .c file except for the implementation of init(set_t *a, int N)?
EDIT
Here's my current implementation of init --> it leads to a segmentation fault
void init(set_t *a, int N) {
//set_t thing[10];
*a = malloc(sizeof(set_t)*N);
for (int i = 0; i < N; i++) {
*(a + i) = i;
}
printf("value of a[2] = %d\n", a[2]);
}
As things currently stand, the requirements imposed on you are wholly unreasonable. If you are building for 32-bit only, so sizeof(int) == sizeof(int *), then you can use brutal casting to get around the constraints. The code will not work on a 64-bit machine, though (unless sizeof(int) == sizeof(int *), which isn't the case on any machine I can immediately think of.
So, the brute force and casting technique is:
void init(set_t *a, int N)
{
assert(sizeof(set_t) == sizeof(set_t *)); // Ick, but necessary!
set_t *base = malloc(sizeof(set_t)*N);
if (base == 0)
*a = 0;
else
{
*a = (int)base; // Brutal; non-portable; stupid; necessary by the rules given!
for (int i = 0; i < N; i++) {
base[i] = i;
printf("value of a[2] = %d\n", base[2]);
printf("value of a[2] = %d\n", ((int *)*a)[2]); // Brutal and stupid too
}
}
Further, in the code in main(), you'll have to use ((int *)a) to make the type usable for dereferencing, etc. Without knowing about what is actually in that other code, it is impossible to be confident that anything will work. It might, but it probably won't.
At this stage, this looks like someone criminally misleading innocent novice programmers. This is not the way it should be coded at all. However, if that's what the doctor (professor) orders, then that's what you've got to do. But it is a mockery of good coding practices AFAICS and AFAIAC.
Professor realized that he had made an error in the assignment and fixed it. Changed set_t a to set_a *a.
Thanks for all your help (hope I didn't cause too many headaches!
I must have tried 20 ways of doing this by now. I really need help, no matter what I do i get a error similar to this one.
a value of type "int" cannot be used to initialize an entity of type "int (*)[30]"
i.e. this will get me such an error
int(*array)[160] = malloc((sizeof *array) * 10);
and doing something like this
int** Make2DintArray(int arraySizeX, int arraySizeY) {
int** theArray;
theArray = (int**) malloc(arraySizeX*sizeof(int*));
int i;
for (i = 0; i < arraySizeX; i++)
{
theArray[i] = (int*) malloc(arraySizeY*sizeof(int));
}
return theArray;
}
will get me this
"void *(size_t)" in "memory.c" at line 239 and: "int()"
does anyone have a solution for how to successful allocate a 2dArray of int[160][10]
Try this:
int **array;
array = malloc(rows * sizeof(int *));
for (i = 0; i < rows; i++)
array[i] = malloc(cols * sizeof(int));
// Some testing
for (i = 0; i < rows; i++) {
for (j = 0; j < cols; j++)
array[i][j] = 0; // or whatever you want
}
for (i = 0; i < rows; i++) {
for (j = 0; j < cols; j++)
printf("%d ", array[i][j]);
}
In your case rows = 160 and cols = 10. Is one possible solution.
With this approach you can use the two indexes:
Both of these compile fine for me. The first error is common when you forget to #include <stdlib.h> prior to using functions declared within said-same (such as malloc(size_t)), which I did not forget to do.
C has some interesting compile-time behaviors, among them the ability to invoke a function that has never been seen before (neither prototype definition nor implementation). Upon encountering such a call, C assumes the function is:
Something that returns int
Takes an unknown number of arguments, so the caller can pass whatever it wants (including the wrong things).
Eg., the function is implicitly assumed to be of the form:
int func();
Often you won't even notice, save for warnings from your compiler that report something to the effect of:
Warning: implicit declaration of `func` assumed to return `int`
and if you're on-the-ball, you have your warning levels turned up with warnings-as-errors enabled and will catch this.
But what if you don't? And what if the "thing" returned from the function cannot be content-represented by the data size in an implementation int ? What if, for example, int were 32-bit, but data pointers were 64-bit? For example, lets assume char *get_str() is declared in some header file you're not including, and implemented in a .c file you compile and link with your program, that looks like this:
#include <stdio.h>
// Note: NO prototype for get_str
int main()
{
char *s = get_str();
printf("String: %s\n", s);
return 0;
}
Well, the compiler should puke, telling you that int and char* are not compatible (shortly after it warns you get_str is assumed to return int). But what if you force the compiler's hand by telling it to make a char* one way or another:
#include <stdio.h>
// Note: NO prototype for get_str
int main()
{
char *s = (char*)get_str(); // NOTE: added cast
printf("String: %s\n", s);
return 0;
}
Now, without warnings-as-errors enabled, you'll get a implicit declaration warning, and thats it. The code will compile. But will it run ? If sizeof(int) != sizeof(char*), (32-bit vs 64-bit) likely not. The value returned from get_str is a 64-bit pointer, but the caller is assuming only 32-bits is returned, then forcing it to a 64-bit pointer. In short, the cast has hidden the error and opened pandora's box of undefined behavior.
So how does all of this relate to your code? By not including <stdlib.h> the compiler doesn't know what malloc is. So it assumes it is of the form:
int malloc();
Then, by casting the result to (int**) you're telling the compiler "whatever comes out of this, make it a int**". At link time, _malloc is found (no parameter signature via name mangling like C++), wired up, and your program is ready to party. But on your platform int and data pointers are not the same size, thus you end up with several undesirable consequences:
The cast hides the real error.
A bogus pointer is manufactured from half the bits of the real returned pointer.
As a cruel dose of salt to the wound, the allocated memory is leaked, as there are no valid pointers anywhere that reference it (you just destroyed the only one by only keeping half of it).
Probably the most undesirable, the code will exhibit normal behavior if compiled on an implementation where sizeof(int) == sizeof(int**).
So you build this on your 32-bit Debian box, all looks well. You turn in your homework to the professor who builds it on his 64bit Mac and it crashes, you fail the assignment, fail the class, drop out of college, and spend the next ten years petting the cat while watching Seinfeld reruns in your mom's basement wonder what went wrong. Ouch.
Don't treat casting like some silver bullet. It isn't. In C, it is needed far less often than people use it, and if used in the wrong place, can hide catastrophic errors. If you find a point in your code where something won't compile without a hard cast, look again. Unless you're absolutely, positively sure the cast is the right thing to do, odds are its wrong.
In this case it hid the real error, that you neglected to give enough info to your compiler to know what malloc really does.
To allocate the array:
int *array = malloc(sizeof(int) * 160 * 10);
Then use code like:
array[10 * row + column] = value;
(Where row goes from 0 to 159 inclusive and column goes from 0 to 9 inclusive.)
I have a note for rendon's answer:
For his code, Visual C++ says for every "=" operations: error C2440: '=' : cannot convert from 'void *' to 'int **'
By making some changes, it works for me, but I'm not sure that it does the same, so I afraid of editing his code. Instead, here's me code, that seems to work for a first impression.
int **a;
a = (int **)malloc(rows * sizeof(int));
for (i = 0; i < rows; i++)
{
a[i] = (int *)malloc(cols * sizeof(int));
}
for (j=0;j<rows;j++)
{
for (i=0;i<cols;i++)
{
a[i][j] = 2;
}
}
Actually, I did it with a custom struct instead of ints but I think either way should it work.
Don't mind me I'm just adding an example using calloc
void allocate_fudging_array(int R, int C)
{
int **fudging_array = (int **) calloc(R, sizeof(int *));
for(int k = 0; k < R; k++)
{
fudging_array[k] = (int*) calloc(C, sizeof(int));
}
}
// a helper function to print the array
void print2darr(int **arr, int R, int C)
{
for(int i = 0; i < R; i++)
{
for(int j = 0; j < C; j++)
{
printf(" %d ", arr[i][j]);
}
printf("\n");
}
}
2D array to store char *
char ***array;
int rows = 2, cols = 2, i, j;
array = malloc(sizeof(char **)*rows);
for (i = 0; i < rows; i++)
array[i] = malloc(cols * sizeof(char *));
array[0][0] = "asd";
array[0][1] = "qwe";
array[1][0] = "stack";
array[1][1] = "overflow";
for(i=0;i<rows;i++){
for(j=0;j<cols;j++){
printf("%s ",array[i][j]);
}
printf("\n");
}