dynamic-variable-sized array

Hi there everyone,

I am writing a function within which a 1D array increases in size (increasing number of elements) inside a loop.

In order to achieve this I used the malloc() and realloc() statements, but neither one seems to allocate the memory correctly, producing an error in execution.

Here is my code; should it not be clear enough, please let me know and Ill give you more information.

thank you in advance,
S.M.

Code:

---


        int *_esup1;
        int *_esup2;
        int _nesup[nnode+1];
        int _szesup1 = 1;
        int CONN[][3] = {{1,2,6},{2,7,6},{2,3,7},{3,8,7},{3,4,8},{4,9,8},{4,5,9},{5,10,9},{7,8,13},{8,12,13},{8,9,12},{9,11,12},{9,10,11}};

        _szesup1 = _esup2[nnode];
        _esup1 = malloc((sizeof(int))*(_szesup1);
       
//Element pass 2: store the elements in _esup1:
        for(_ielem=0; _ielem<=12; _ielem++){
                for(_inode=0; _inode<=2; _inode++){
                //Update storage counter, storing in _esup1:
                        _ipoin = CONN[_ielem][_inode];
                        _istor = _esup2[_ipoin-1] + 1;
                        _esup2[_ipoin-1] = _istor;
                       
                        _esup1 = malloc((sizeof(int))*(_istor));
                        printf("_istor %d\t size(ESUP1) %d\n",_istor, sizeof(_esup1));
                        _esup1[_istor] = _ielem;

                }
        }

---

You are using malloc twice, not malloc and realloc... Mistake?
This, in turn, causes memory leaks.

If you were using realloc, instead of malloc, then that would be a good start.

When you do

Code:

---

_esup1 = malloc((sizeof(int)*(_istor));

---

then the one thing you most assuredly do not have is

Code:

---

_esup1[_istor]

---

If you ask for _istor elements (with malloc), then you get _istor elements, so trying to access the _istor+1'th element (with _esup1[_istor]) is not going to work very well.

You should check the result of malloc, if it's not a null pointer, then the allocation is correct and the runtime error (segv I assume) is due to an incorrect memory access, which is another problem.

Hi there Elysia,

Quote:

---

Originally Posted by Elysia

You are using malloc twice, not malloc and realloc... Mistake?
This, in turn, causes memory leaks.

---

I actually obtain the same error in executaion either by using malloc again inside the loop or realloc.

Or better said, I do not get an error of memory allocation (sorry about that if I wrote that earlier), I do not get to fill the array at every loop step with the correct assignment of element values.

At every loop step I am supposed to add a new element to the array, and assign it the value "_elem", but this does not happen

Thank you again
S.M.

Quote:

---

Originally Posted by root4

...segv I assume...

---

In Linux maybe. In Windows, that would probably be a page fault.
It's not good to assume what OS someone is using.
Regardless, I would just classify it as a crash and/or undefined behavior.

Quote:

---

Originally Posted by simone.marras

Code:

---


        int *_esup1;
        int *_esup2;
        int _nesup[nnode+1]; // Is _nesup initialized?
        int _szesup1 = 1;
        int CONN[][3] = {{1,2,6},{2,7,6},{2,3,7},{3,8,7},{3,4,8},{4,9,8},{4,5,9},{5,10,9},{7,8,13},{8,12,13},{8,9,12},{9,11,12},{9,10,11}};

        _szesup1 = _esup2[nnode]; // _esup2 is not initialized!!!
        _esup1 = malloc((sizeof(int))*(_szesup1); // Size in _szesup1 is undefined!!!
       
//Element pass 2: store the elements in _esup1:
        for(_ielem=0; _ielem<=12; _ielem++){
                for(_inode=0; _inode<=2; _inode++){
                //Update storage counter, storing in _esup1:
                        _ipoin = CONN[_ielem][_inode];
                        _istor = _esup2[_ipoin-1] + 1; // [B][COLOR="Red"]_esup2 is not initialized!!!
                        _esup2[_ipoin-1] = _istor;
                       
                        _esup1 = malloc((sizeof(int))*(_istor)); // To extend the storage of a block of memory, you must use realloc!
                        printf("_istor %d\t size(ESUP1) %d\n",_istor, sizeof(_esup1));
                        _esup1[_istor] = _ielem;

                }
        }

---

---

Few comments.

Thank you again,

Quote:

---

Originally Posted by Elysia

Few comments.

---

about your comments, I agree but consider that the code I put is missing a whole part above where I allocate those variables that do not appear allocated in here (just for the sake of shortness in the thread); so, speakign fo that, the allocation of every other variable was done.

Now though, I changed the malloc() inside the loop with the realloc as follows:

Code:

---

       
for(_ielem=array_numb; _ielem<=nelem-1+array_numb; _ielem++){
                for(_inode=array_numb; _inode<=max_nnode-1+array_numb; _inode++){
                //Update storage counter, storing in _esup1:
                        _ipoin = CONN[_ielem][_inode];
                        _istor = _esup2[_ipoin-1] + 1;
                        _esup2[_ipoin-1] = _istor;
                       
                        _esup1 = realloc(_esup1, (sizeof(int))*(_istor));

                        printf("_istor %d\t size(ESUP1) %d\n",_istor, sizeof(_esup1));
                        _esup1[_istor] = _ielem;

---

but I obtaine a memory allocation error now:

Code:

---

*** glibc detected *** ./testing.exe: realloc(): invalid next size: 0x175004a8 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb7c89803]
/lib/tls/i686/cmov/libc.so.6(realloc+0x10b)[0xb7c8b75b]
./testing.exe[0x8049195]
./testing.exe[0x80488c7]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7c32450]
./testing.exe[0x8048771]
======= Memory map: ========
08048000-0804b000 r-xp 00000000 08:02 516097    /home/simone/Documents/scientific/CFD/myCFD_library/testing_myCFDlibrary/testing.exe
0804b000-0804c000 rw-p 00002000 08:02 516097    /home/simone/Documents/scientific/CFD/myCFD_library/testing_myCFDlibrary/testing.exe
0804c000-0806d000 rw-p 0804c000 00:00 0          [heap]
17500000-17521000 rw-p 17500000 00:00 0
17521000-17600000 ---p 17521000 00:00 0
1764c000-b7bf7000 rw-p 1764c000 00:00 0
b7bf7000-b7c1a000 r-xp 00000000 08:02 2293788    /lib/tls/i686/cmov/libm-2.7.so
b7c1a000-b7c1c000 rw-p 00023000 08:02 2293788    /lib/tls/i686/cmov/libm-2.7.so
b7c1c000-b7d65000 r-xp 00000000 08:02 2293784    /lib/tls/i686/cmov/libc-2.7.so
b7d65000-b7d66000 r--p 00149000 08:02 2293784    /lib/tls/i686/cmov/libc-2.7.so
b7d66000-b7d68000 rw-p 0014a000 08:02 2293784    /lib/tls/i686/cmov/libc-2.7.so
b7d68000-b7d6c000 rw-p b7d68000 00:00 0
b7d6c000-b7d9c000 r-xp 00000000 08:02 681117    /usr/local/lib/libgslcblas.so.0.0.0
b7d9c000-b7d9d000 rw-p 0002f000 08:02 681117    /usr/local/lib/libgslcblas.so.0.0.0
b7d9d000-b7f1c000 r-xp 00000000 08:02 681124    /usr/local/lib/libgsl.so.0.10.0
b7f1c000-b7f26000 rw-p 0017f000 08:02 681124    /usr/local/lib/libgsl.so.0.10.0
b7f2e000-b7f38000 r-xp 00000000 08:02 2294001    /lib/libgcc_s.so.1
b7f38000-b7f39000 rw-p 0000a000 08:02 2294001    /lib/libgcc_s.so.1
b7f39000-b7f3c000 rw-p b7f39000 00:00 0
b7f3c000-b7f3d000 r-xp b7f3c000 00:00 0          [vdso]
b7f3d000-b7f57000 r-xp 00000000 08:02 2295295    /lib/ld-2.7.so
b7f57000-b7f59000 rw-p 00019000 08:02 2295295    /lib/ld-2.7.so
bff85000-bff9a000 rw-p bffeb000 00:00 0          [stack]
Aborted

---

thank you again for all the help and patience!

Then, if you please, can you post the smallest possible sample that demonstrates the problem? I have a hard time sorting through all of the variables and what they do, as well as what values they contain.

Code:

---

for(_ielem=array_numb; _ielem<=nelem-1+array_numb; _ielem++){
                for(_inode=array_numb; _inode<=max_nnode-1+array_numb; _inode++){
                //Update storage counter, storing in _esup1:
                        _ipoin = CONN[_ielem][_inode];
                        _istor = _esup2[_ipoin-1] + 1; //?
                        _esup2[_ipoin-1] = _istor; //?
                       
                        _esup1 = realloc(_esup1, (sizeof(int))*(_istor));

                        printf("_istor %d\t size(ESUP1) %d\n",_istor, sizeof(_esup1));
                        _esup1[_istor] = _ielem;  //BOOOM!

---

So (1) Why realloc one more every time (I think that's what the two lines labeled //? are supposed to do, but it's not quite clear where the numbers are coming from), and (2) the line labeled //BOOOM! is still a really really really really big error.

Quote:

---

Originally Posted by Elysia

Then, if you please, can you post the smallest possible sample that demonstrates the problem? I have a hard time sorting through all of the variables and what they do, as well as what values they contain.

---

Sorry about that, sure, here a more readable version of the code with the correct allocation of the used variables; I hope this helps

Code:

---

      int *_esup1;
        int *_esup2;
      int _szesup1;
        int CONN[][3] = {{1,2,6},{2,7,6},{2,3,7},{3,8,7},{3,4,8},{4,9,8},{4,5,9},{5,10,9},{7,8,13},{8,12,13},{8,9,12},{9,11,12},{9,10,11}};

      //Allocate _esup2:
        _esup2 = (int*) malloc((sizeof(int[nnode+1])));

      //First allocation of _esup1:
        _szesup1 = 1;
        _esup1 = malloc((sizeof(int))*(_szesup1);
       
      //Store the elements in _esup1:
        for(_ielem=0; _ielem<=12; _ielem++){
                for(_inode=0; _inode<=2; _inode++){
                //Update storage counter, storing in _esup1:
                        _ipoin = CONN[_ielem][_inode];

                        _istor = _esup2[_ipoin-1] + 1;

                        _esup2[_ipoin-1] = _istor;
                       
                        _esup1 = realloc(_esup1, (sizeof(int))*(_istor));

                        _esup1[_istor] = _ielem;

                }
        }

---

thank you very much (Ill be back in about 45 minutes, so if I doent reply it's not for rudeness!)
S.M.

nnode, _istor and _ipoin is missing... I'll try hacking them in.
EDIT: Done. Got a crash. I will investigate.

Had a question about the lines highlighted red.

Code:

---

      int *_esup1;
        int *_esup2;
      int _szesup1;
        int CONN[][3] = {{1,2,6},{2,7,6},{2,3,7},{3,8,7},{3,4,8},{4,9,8},{4,5,9},{5,10,9},{7,8,13},{8,12,13},{8,9,12},{9,11,12},{9,10,11}};

      //Allocate _esup2:
        _esup2 = (int*) malloc((sizeof(int[nnode+1])));

      //First allocation of _esup1:
        _szesup1 = 1;
        _esup1 = malloc((sizeof(int))*(_szesup1);
       
      //Store the elements in _esup1:
        for(_ielem=0; _ielem<=12; _ielem++){
                for(_inode=0; _inode<=2; _inode++){
                //Update storage counter, storing in _esup1:
                        _ipoin = CONN[_ielem][_inode];

                        _istor = _esup2[_ipoin-1] + 1; /* _esup2 is not initialized yet */

                        _esup2[_ipoin-1] = _istor; /* sequence?? shouldn't the one above come after this one */
                       
                        _esup1 = realloc(_esup1, (sizeof(int))*(_istor));

                        _esup1[_istor] = _ielem;

                }
        }

---

Quote:

---

Originally Posted by Elysia

nnode, _istor and _ipoin is missing... I'll try hacking them in.
EDIT: Done. Got a crash. I will investigate.

---

Im back; here some numbers and types that I am actually using to run this:

int _ielem;
int _inode;
int _istor;
int nnode = 13;

I have a main.c written on purpose to test this function; I can send them both to you by this thread if you think it may help. The reason why I ask is due to the fact that the main.c and the function use much more variables than those already appearing in this thread, and that may cause some confusion.

Please those interested, let me know if you want the two codes as well

Thanks you
S.M.

Well, I feel confident that I've identified the immediate crash, above. But I, and others, have identified some other suspicious lines as well, but there's no way we can be sure without the whole context. If it's large, you can always attach rather than paste.

Quote:

---

Originally Posted by tabstop

Well, I feel confident that I've identified the immediate crash, above. But I, and others, have identified some other suspicious lines as well, but there's no way we can be sure without the whole context. If it's large, you can always attach rather than paste.

---

Hi tabstop, thanks for replying. I attach the following files:

main.c
PSUP.c (the function object of this thread)
PSUP.h
makefile.txt (CHANGE makefile.txt into makefile)
README.txt

Thanks a lot for helping

S.M.

So, these two lines:

Code:

---

                        _istor = _esup2[_ipoin-1] + 1;
                        _esup2[_ipoin-1] = _istor;

---

_ipoin doesn't change inside this for-loop (element pass 2), so all that happens is that you continually add one to _istor. There's nothing wrong with that, I guess, except you know how many times this for loop is going to run (it says so at the top -- nelem), so just add nelem to _esup2[_ipoin-1] and realloc outside the loop -- growing your array one element at a time is worse than useless.

And still, _esup1[_istor] doesn't exist, so any attempt to set it equal to _elem is doomed to failure.

Quote:

---

Originally Posted by tabstop

So, these two lines:

Code:

---

                        _istor = _esup2[_ipoin-1] + 1;
                        _esup2[_ipoin-1] = _istor;

---

_ipoin doesn't change inside this for-loop (element pass 2), so all that happens is that you continually add one to _istor. There's nothing wrong with that, I guess, except you know how many times this for loop is going to run (it says so at the top -- nelem), so just add nelem to _esup2[_ipoin-1] and realloc outside the loop -- growing your array one element at a time is worse than useless.

And still, _esup1[_istor] doesn't exist, so any attempt to set it equal to _elem is doomed to failure.

---

Thank you again; actually _ipoin does change inside the loop (element pass 2) because at every loop it is assigned the value of CONN[_ielem][_inode]. It it werent, I agree with you that I should just add nelem to _esup2[_ipoin-1].

Given this, about the "nonexisting" _esup1[_istor], I dont understand why it doesn't exist: when I use the line

Code:

---

_esup1 = realloc(_esup1, (sizeof(int))*(_istor))

---

am I not indeed allocating a number of elements equal to _istor ?

Simone

Yes, you're right about _ipoin -- missed that, sorry.

Your realloc line does indeed allocate a number of elements equal to _istor. Since you immediately try to access the _istor+1'th element (_esup1[_istor] is the _istor+1'th element of _esup1), that doesn't help.

Quote:

---

Originally Posted by simone.marras

Thank you again; actually _ipoin does change inside the loop (element pass 2) because at every loop it is assigned the value of CONN[_ielem][_inode]. It it werent, I agree with you that I should just add nelem to _esup2[_ipoin-1].

Given this, about the "nonexisting" _esup1[_istor], I dont understand why it doesn't exist: when I use the line

Code:

---

_esup1 = realloc(_esup1, (sizeof(int))*(_istor))

---

am I not indeed allocating a number of elements equal to _istor ?

Simone

---

You are. But in C, array indices start at 0 and end at (number_of_elements-1), so you can access from _esup1[0] up to _esup1[_istor-1]. _esup1[_istor] will be elemennt number _istor+1.

By the way, has anyone else told you that you should really not use _ in the beginning of variable names - such names are reserved, by the C standard, for the compiler and OS vendors to use - and you can get into trouble if you make it a habit [I'm sure it's not a problem right now - but if you do it for long enough and with many enough variable names, you will sooner or later run into a problem because of that naming convention].

Quote:

---

Originally Posted by matsp

By the way, has anyone else told you that you should really not use _ in the beginning of variable names - such names are reserved, by the C standard, for the compiler and OS vendors to use - and you can get into trouble if you make it a habit [I'm sure it's not a problem right now - but if you do it for long enough and with many enough variable names, you will sooner or later run into a problem because of that naming convention].

---

Hey Mat, I actually didn't know about the underscore in front of the variables! Thank you about that, I will change my convention to identify local variables.

And yes, I was allocating one less element, infact now that I allocate _istor+1 element instead, I get no more problems. I thought that the problem was somewhere else!

I now get wrong assignments to the elements of my array, but I will get back here if I cant get that solved on my own. A big part of the problem is now solved

Thank you again to all who helped,

Best regards and happy new year
S.M.

Another line in your source code that looks suspicious is:

Code:

---

_esup2 = (int*) malloc((sizeof(int[nnode+1])));

---

if you're trying to allocate storage equal to 14 ints [given that nnode = 13] then the expression supplied to sizeof should be:

Code:

---

_esup2 = (int*) malloc(sizeof(int)*(nnode+1));

---

otherwise your program will crash with SIGSEGV.

Quote:

---

Originally Posted by matsp

By the way, has anyone else told you that you should really not use _ in the beginning of variable names - such names are reserved, by the C standard, for the compiler and OS vendors to use - and you can get into trouble if you make it a habit [I'm sure it's not a problem right now - but if you do it for long enough and with many enough variable names, you will sooner or later run into a problem because of that naming convention].

---

Well, but that's extern only, innit? The system gets all double underscores, and underscore + capital letter names, plus things with underscore at file scope. So this should be fine, I think.

Quote:

---

Originally Posted by tabstop

Well, but that's extern only, innit? The system gets all double underscores, and underscore + capital letter names, plus things with underscore at file scope. So this should be fine, I think.

---

But you do not know under which circumstances the compiler/OS will use these variables. E.g. errno may expand to a macro that uses "_error[current_thread()]" - now try compiling that with a local int called _error...

Ok, so that's probably not very likely to be the case - but you get the idea.

DO NOT USE RESERVED NAMES - EVER!

As to "identifying local variables", I'd first of all say that it's much more important to know about variables that are NOT local - globals, member variables [c++] and perhaps parameters. Where I work, we have naming conventions for member variables and arguments to indicate such. Local variables are just "lower-case inital, camelcase, and sensible name" (the same rules apply to globals - but those are very rare and in code-review where a global variable is introduced will gain a comment "Why are you using global here" or some such).

--
Mats

Quote:

---

Originally Posted by itCbitC

otherwise your program will crash with SIGSEGV.

---

Why do people keep assuming Linux? Do not!

> Why do people keep assuming Linux? Do not!
But there will be a segfault signal, even if you're on Windows. Sure it may be worded differently, but it's the same thing. Just as "Directory" and "Folder".

But in Windows, you would never hear the term sigsev or whatever. You would hear page fault or crash.
Windows != Linux. People must learn this.
As it always has been. As it always will be. As it always must be.

You failed to see my point... SIGSEGV (Signal Segmentation Fault) is a part of the POSIX (Note: NOT just Unix/Linux) standard, something Windows partly adopted in the past.

Hell it's even on MSDN http://msdn.microsoft.com/en-us/library/xdkz3x12.aspx
Note that SIGSEGV and signal()* is even a part of .NET!

* signal() is a part of standard C

My point was that Windows users aren't as geeky as Linux users, and usually not many breathes the name SIGSEGV.
We hear crash. Perhaps page fault, at best. Not SIGSEGV. Linux talk.
But whatever...

Not to mention of course that going over the edge of the allocation is by no means guaranteed to fail in any particular manner - it is simply undefined behaviour.

--
Mats

> We hear crash. Perhaps page fault, at best. Not SIGSEGV. Linux talk.
It's programmer talk, you should know what a signal is. And you should know what a segfault is.

As far as it goes, if it's in MSDN I'd expect a Windows programmer to acknowledge it ;). But MSDN is huge, and too I do see your point... so whatever :p

Quote:

---

Originally Posted by matsp

But you do not know under which circumstances the compiler/OS will use these variables. E.g. errno may expand to a macro that uses "_error[current_thread()]" - now try compiling that with a local int called _error...

---

I suspect that we could classify that as a compiler bug rather than a user mistake. I would rather say that it is better to avoid such names entirely to avoid actually using a reserved name when a mistake places it in a context where it is reserved.

Quote:

---

Originally Posted by zacs7

> We hear crash. Perhaps page fault, at best. Not SIGSEGV. Linux talk.
It's programmer talk, you should know what a signal is. And you should know what a segfault is.

As far as it goes, if it's in MSDN I'd expect a Windows programmer to acknowledge it ;). But MSDN is huge, and too I do see your point... so whatever :p

---

I would say page fault.

Quote:

---

Originally Posted by Elysia

I would say page fault.

---

However, it may not be that - it may actually be a "segment fault" (general protection error) if the system is running in x86 protected mode using segments.

If we are not to assume that it is running any particular OS, then don't use terms that are specific to how the OS happens to implement its memory protection.

--
Mats

Yes, page fault or seg fault or something. I am not 100% on what those terms mean because I have never needed them.
I am not a Linux dev.

Quote:

---

Originally Posted by laserlight

I suspect that we could classify that as a compiler bug rather than a user mistake. I would rather say that it is better to avoid such names entirely to avoid actually using a reserved name when a mistake places it in a context where it is reserved.

---

Really? How would you make the internal implementation of the errno expansion work, then? Most C libraries provide errno as a implementation specific macro that takes into account the current thread so that errno's are thread-safe. Unless we are using C++ where we could use namespaces, the only thing that would make errno expand in a way that is unlikely to collide with user-defined names is to use a name that is reserved for the compiler/library implementation - it may not be the names I've suggested, but it should be a name that is specific to the C-runtime.

--
Mats

Quote:

---

Originally Posted by matsp

Not to mention of course that going over the edge of the allocation is by no means guaranteed to fail in any particular manner - it is simply undefined behaviour.

---

Speaking of that, I was trying to make sense of the syntax, and apparently int[nnode+1] is a temporary variable length array. This would mean that sizeof(int[nnode+1]) == sizeof(int)*(nnode+1), if I understand variable length arrays correctly. Consequently, the whole point about segfault/page fault would be irrelevant.

Quote:

---

Originally Posted by matsp

How would you make the internal implementation of the errno expansion work, then?

---

Use __errno instead of _errno since __errno is reserved for any use.

Quote:

---

Originally Posted by laserlight

Use __errno instead of _errno since __errno is reserved for any use.

---

Ok, yes. But isn't _xxx also reserved?

Either way, I think it's not a bad idea to avoid using any prefix based on underscore, just to avoid any possibility of getting into trouble, don't you agree?

--
Mats

Quote:

---

Originally Posted by matsp

Ok, yes. But isn't _xxx also reserved?

---

In file scope only, so I would think that using it with a macro intended for use in any scope would be a bug.

Quote:

---

Originally Posted by matsp

Either way, I think it's not a bad idea to avoid using any prefix based on underscore, just to avoid any possibility of getting into trouble, don't you agree?

---

Of course, assuming that you are not implementing the implementation.

Quote:

---

Originally Posted by laserlight

Speaking of that, I was trying to make sense of the syntax, and apparently int[nnode+1] is a temporary variable length array. This would mean that sizeof(int[nnode+1]) == sizeof(int)*(nnode+1), if I understand variable length arrays correctly. Consequently, the whole point about segfault/page fault would be irrelevant.

---

It very well might be that sizeof(int[nnode+1]) == sizeof(int)*(nnode+1) but the use of a reserved keyword might confuse the heck out of people like me for instance :confused: and if they are equivalent then page fault or sigsegv wouldn't come into play.

Quote:

---

Originally Posted by Elysia

But in Windows, you would never hear the term sigsev or whatever. You would hear page fault or crash.
Windows != Linux. People must learn this.
As it always has been. As it always will be. As it always must be.

---

You're right Elysia "Linux is Linux and Windows is Windows and never the twain shall meet"

Quote:

---

Originally Posted by itCbitC

It very well might be that sizeof(int[nnode+1]) == sizeof(int)*(nnode+1) but the use of a reserved keyword might confuse the heck out of people like me for instance

---

What do you mean by "use of a reserved keyword"? The use of sizeof is correct in this case.

Quote:

---

Originally Posted by itCbitC

You're right Elysia "Linux is Linux and Windows is Windows and never the twain shall meet"

---

Code:

---

  L
  i
Windows
  u
  x

---

Quote:

---

Originally Posted by laserlight

What do you mean by "use of a reserved keyword"? The use of sizeof is correct in this case.

---

I mean int

Quote:

---

Originally Posted by laserlight

Code:

---

  L
  i
Windows
  u
  x

---

---

At the very least orthogonality ;)

Quote:

---

Originally Posted by itCbitC

I mean int

---

Ah, but that is actually not as confusing as it looks at first. I put the code to the MinGW port of gcc 3.4.5, and since I did not enable the -std=c99 flag at the time, it gave the warning "ISO C90 forbids variable-size array `type name'". It then became clear that just as int[N] is the type of an int array of size N, int[nnode+1] is an int array of size nnode+1, even if nnode is a variable, assuming that the variable length arrays feature is available.

Quote:

---

Originally Posted by laserlight

Ah, but that is actually not as confusing as it looks at first. I put the code to the MinGW port of gcc 3.4.5, and since I did not enable the -std=c99 flag at the time, it gave the warning "ISO C90 forbids variable-size array `type name'". It then became clear that just as int[N] is the type of an int array of size N, int[nnode+1] is an int array of size nnode+1, even if nnode is a variable, assuming that the variable length arrays feature is available.

---

I never ran it through a compiler except now and what's interesting is that the C89 one works for me while the C99 one gives errors. Oh well live and learn.