ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
The problem is most likely in how memory is allocated or freed, or in the type of data structure that you're trying to allocate memory for... and you haven't posted any of that.
Try to assemble the smallest piece of compileable code which demonstrates the problem that you're having... often, the process of isolating the problem this way will uncover the source of the memory issue.
Arrays in C count from 0 to size-1, and so your loops need changing, nl should be initialised to 0 and the loop should be i<nh (rather than i <=nl)
There may be other errors along these lines such as size. But so long as you understand how the C index works you should be able to figure them out.
Last edited by graemef; 05-27-2010 at 12:15 AM.
Reason: different slant on the logic
I wanted to create 100 "dx" and 100 "dy" values. So I get 100 "shift" values.
so instead of vector dx[1...100] I was writing dx[1...10] since I was setting nl=1 and nh=10. Same thing I was doing for "dy".
This was my mistake:
Quote:
#define size 100
#define nl 1
#define nh 10
Also, I changed the sensor_matrix[][] indices for avoiding confusion:
Arrays in C count from 0 to size-1, and so your loops need changing, nl should be initialised to 0 and the loop should be i<nh (rather than i <=nl)
There may be other errors along these lines such as size. But so long as you understand how the C index works you should be able to figure them out.
Have you heard about "Numerical Recipes in C"?
Please read this book. Then you can see that 0-offset is not necessary for C arrays. We can have unit-offset too in C arrays. and that is what I am using in my code....When we are dealing with matrices, unit-offset is advisable; when we are dealing with coefficients of polynomials, then zero-offset is best. It depends on the problem you are handling.
Arrays in the C language are zero based, this is to allow pointer arithmetic.
This doesn't stop functions from being written that provide a different approach which is what I suspect you have. However, if you are using such a suite of functions then I would expect that all your access would need to be through these functions. Given that C doesn't provide operator overloading I would suggest that your use of the subscript [] is erroneous.
That all seems to be inconsistent with the "I get segmentation fault here" indication in your first post. IIUC, the problem turns out to be in part of the code you didn't include in your first post.
You figured it out without our help this time. I guess that lets you learn more than if you actually needed our help.
But if some time you actually need help, remember that posting a code fragment with a guess about the problem generally won't get you any real help. You need to post enough context. Usually you need to post an entire testable program.
Quote:
Originally Posted by graemef
Arrays in the C language are zero based, this is to allow pointer arithmetic.
This doesn't stop functions from being written that provide a different approach which is what I suspect you have. However, if you are using such a suite of functions then I would expect that all your access would need to be through these functions.
But a pointer in C doesn't need to point exactly to the object that will be accessed by that pointer.
The suite of functions is used for all the allocation and deallocation operations, so that ordinary C can be used for all the access.
For a simple example:
int hidden_array[10];
int *fake_array = hidden_array-1;
Then use fake_array as if it were an array whose element are numbered 1 to 10. It all works.
Obviously accessing element 0 or 11 of fake_array is unsound, but that is no different than element -1 or 10 of hidden_array.
The suite of functions hides the allocation of the real array as well as the pointer adjustment before returning the result to the caller as well as the reverse pointer adjustment during deallocation.
I actually do have a copy of Numerical Recipes In C by Press et al. I recommend that you take those recipes with at least a grain of salt. It is apparent to me and many other reviewers of the book that the authors were not, in fact, very experienced with C. From the array indexing ranges you cited, I and many other people I talked with about that book concluded that the authors' programming background was probably in FORTRAN. C always indexes an n-element array from 0 to n-1, not from 1 to n. If you demand to index from 1 to n, you need to declare your arrays as size n+1 in each dimension, which wastes a lot of space because you are allocating space for the 0 row and the 0 column of every other row in the array. Most C programmers find artificially reindexed arrays with loop indexes from 1 to n with array indexes artificially offset to be poor coding style at best.
There is actually a common name for such reindexing and certain other related artifacts used in C. We call it C-TRAN. It is considered a pejorative term.
Your segmentation fault occurred when your array indexes put your access outside of the space allocated for the array. In some cases, this could happen quietly with far worse results. Memory pages in Linux are 4kiB. Memory protection is implementable only with a granularity of that page size. If your array were small enough to not extend outside of your page, and if you had other local variables past the top of your array, you could easily be stomping all over other data without causing a segmentation fault. That is the sort of bug that could take a long time to locate.
At least some of the algorithms in the cited book are known to be unreliable. The particular case I know about involves Bessel functions. It may fail to find an answer and return garbage value without any error indication. I believe there are other instances where the algorithm either performs very poorly (i.e., slower than the standard algorithms) or actually returns incorrect results. But the book ended up on my less preferred list when I saw the 1-based indexing and proof of the failures in the Bessel functions.
I can't say that the book over all is not useful. I just want to warn you that the programming practices and algorithms that you find in a published book may not be the best or even necessarily correct.
If you demand to index from 1 to n, you need to declare your arrays as size n+1 in each dimension, which wastes a lot of space because you are allocating space for the 0 row and the 0 column of every other row in the array.
As johnsfine pointed out you don't have to have this wasted space, just use an overlay array with an initial negative offset. For a matrix it will be offset (negatively) by the number of columns plus one, and I assume this can be done in more dimensions but I don't see much gain from such an approach.
But I agree introducing such a concept in a book doesn't gain much and it would be at the expense of their credibility.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.