dynamic-variable-sized array

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 ;)