Talk:Segmentation fault

From Wikipedia, the free encyclopedia

What is a segmentation fault ? Why does the Turbo C compiler doesn't shows it while it is rampant in the GNU compiler? —Preceding unsigned comment added by 203.76.128.203 (talk • contribs)

It is nothing to do with compilers, it is an operating system thing. NicM 07:35, 28 April 2006 (UTC).

If we are talking about C, then you're wrong; it is entirely possible for two compilers that compile to the same platform to produce a program that behaves differently, and "platform" includes both the operating system and the processor model. So you can have a program that segfaults with one compiler and does not segfault with another, on the same platform, and that's without regarding any issues of optimization.

You are right inasmuch that Turbo C is a DOS-only compiler, and DOS and the processor models it runs on do not have any protection mechanisms (so segfaults simply cannot occur), while GNU C is a compiler that, to my knowledge, has never been ported to 16-bit DOS, so the OP is definitely talking about different platforms. (DJGPP is a GNU C port for 32-bit protected mode, so it's not relevant here.) 82.92.119.11 13:02, 6 May 2006 (UTC)

I am not wrong at all. The fact that different compilers produce different code does not make segfaults anything more than an interaction between running code and the platform on which it is running. Sure, compilers can produce different code which may segfault, or through a bug or programmer error produce code that ends up with a segfault, but that doesn't redefine segfault to make it a direct product of the compiler. A segfault is is an attempt to illegally access protected memory, nothing more. For normal users they are as often caused by hardware faults as incorrect code or compiler bugs. NicM 07:03, 2 June 2006 (UTC).

I simply contradicted your statement that "it has nothing to do with compilers". It does at least have something to do with the compiler, inasmuch that one compiler can turn a program into object code which consistently segfaults while another does not (even assuming the hardware and both compilers are flawless). I don't dispute the fact that the segfault isn't a direct product of the compiler, and I never claimed that it was. I pick my nits very carefully. :-)

The OP, of course, was just confused about the nature of segfaults; programs compiled with Turbo C never segfault because the object code runs on a platform that doesn't have a concept of protected memory, but this is an implementation accident. I was just pointing out that your statement wasn't strictly correct. 82.92.119.11 20:41, 8 June 2006 (UTC)

The GNU compiler doesn't run on dos. Compiling the program in GNU necessarily means that it was compiled on a different operating system than the program compiled by Turbo C. Even if it has has the same hardware and both compilers are flawless.

I'm not acquainted with whether or not the compiler can effect seg faults (I actually would think it could), but the logic here is completely flawed. You completely ignored, or maybe even didn't understand, the previous posts. If it is true, it's not because of the whole turbo C vs gcc thing.

This page should most certainly be merged with that for Access violation; the terms are synonymous. Since the page Segmentation fault is the more detailed of the two, including all information presented by that for Access violation, I propose that the latter simply be linked to the former.74.131.87.98 22:37, 1 June 2006 (UTC)

I agree. Access violation is also misleading wrt segments. NicM 07:06, 2 June 2006 (UTC).

I've redirected Access violation to here, per this discussion. Kevin 08:40, 24 June 2006 (UTC)

The second code sample does not necessarily initialize a pointer to address zero. It initializes it using the null pointer constant, which sets it to a value which cannot represent a valid memory address. That is not necessarily address zero.

See C FAQ:

http://c-faq.com/null/null1.html

and

http://c-faq.com/null/accessloc0.html

131.128.160.100 (talk) 19:07, 20 February 2008 (UTC)

[edit] OpenBSD vs. Linux ?!?

What's the point of comparing gcc's behaviour under OpenBSD vs. Linux? AFAIK the presence of absence or a compilation-time error has nothing to do with the OS, it depends on the behaviour of different gcc versions.--88.149.248.200 (talk) 02:51, 29 February 2008 (UTC)

But a segmentation fault is not a compile time error, Its a runtime error. —Preceding unsigned comment added by 124.150.80.158 (talk) 03:07, 21 March 2008 (UTC)

Sorry you are right in the version that is run on linux it is picked up at compile time --124.150.80.158 (talk) 03:09, 21 March 2008 (UTC)