Seg fault even though address space is accessible

[31349 83652]

I haven't figured out what are best compiler options yet.

I can't help you there (and the options may change for
each translation unit), but maybe you'd like to try


gcc -Werror ...

-Werror
Make all warnings into errors.

 

[Antoninus Twink]

Cite three instances that fit this claim.

Happily. In fact, here are five.

My view on this is that the debugger creates a very intimate
relationship with the programmer. When I first learnt C I used one.
The run / debug cycle becomes a natural way of working. Then In my
first job I got a Unix box and suddenly the debugger was taken away.
Then I got another one for a games console, but it wasn't well
designed. I decided at that point that even a good debugger was too
seductive. So now I use diagnostics almost exclusively.

I've never used debuggers either, for either hardware or software.
Tracking down an elusive bug is more like a sport; a proper debugger
would spoil the fun.

As I've said here before, spend some time (at least a year) working in
a language without a debugger, you will very quickly adapt to life
without it.

Ed Prochik,

So then keep you code size below that limit and you will not need the
debugger.

And the Prince Of Lies himself, Richard Heath Field,

I have certainly debugged what you consider to be impossibly large
code bases without using a debugger.


...except those who've done it, of course, which seems to be most of
us.

Once again, I call bullshit on Heathfield's claims to be a superhero.

We've all seen Heathfield spew out lie after lie to undermine Jacob and
try to destroy his reputation. It's no surprise that he tries to blacken
the "trolls" who've got the measure of him with the same sort of slurs.

Heathfield is a liar, morning, noon and night.

 

[Nick Keighley]

Happily. In fact, here are five.

the key sentence in your quote is:

"You [Richard Heathfield] [...] have claimed on many occasions that
you can
debug any problem using ONLY a printout of the source code and NEVER
a
debugger"

I do not believe my elision or change in emphasis has distorted
what you say. The original is still available above.

1. RCH never said he nver used a debugger
2. none of the quotes below claim to only use a printout.
Many use diagnostics.

So you have made two untrue statements. Since you have done
this repeatedly this makes you a liar.

Ed Prochik,



And the Prince Of Lies himself, Richard Heath Field,



Once again, I call bullshit on Heathfield's claims to be a superhero.

We've all seen Heathfield spew out lie after lie to undermine Jacob and
try to destroy his reputation. It's no surprise that he tries to blacken
the "trolls" who've got the measure of him with the same sort of slurs.

Heathfield is a liar, morning, noon and night.

--
Nick Keighley

"Anyone attempting to generate random numbers by deterministic
means is, of course, living in a state of sin."
-- John Von Neumann

 

[Harald van Dijk]

One line, probably wrapped, below:

*gcc -W -Wall -ansi -pedantic -Wwrite-strings -Wfloat-equal -gstabs+
-ftrapv

(you may want to replace ansi with std=c99)

Why do you want to use -ansi if you're going to include another option
that deliberately makes the compiler fail to conform to any standard?

 

[Ben Bacarisse]

And what do you consider does that? A warning does not prevent
compilation.

Consider the following:

void f(const char (*cp)[4]);

void g(void)
{
f(&"abc");
}

It requires a diagnostic which -Wwrite-strings suppresses.

 

[Harald van Dijk]

Harald van D?k wrote:
... snip ...

Why do you want to use -ansi if you're going to include another
option that deliberately makes the compiler fail to conform to any
standard?

And what do you consider does that? A warning does not prevent
compilation.

Consider the following:

void f(const char (*cp)[4]);

void g(void) { f(&"abc"); } /* modified cf */

It requires a diagnostic which -Wwrite-strings suppresses.

I don't see that. Are you confused about the meaning of
-Wwrite-strings?

He's not.

The type of "abc" according to the standard is char[4], not const char[4].
And the type of &"abc" is char(*)[4], not const char(*)[4]. There is no
implicit conversion from char(*)[4] to const char(*)[4], so Ben's code
violates a constraint. And if you make the code

void f(char (*cp)[4]);
void g(void) { f(&"abc"); }

then the code is correct, no constraint is violated, and gcc will accept
the code, but it will emit a very misleading diagnostic strongly
suggesting the code is incorrect.

Admittedly a stretch, but you can even get gcc to reject valid code with
your options:

void f(void) { *"" = 0; }

This is allowed in a strictly conforming program as long as f is never
called, yet gcc will issue a hard error for it with your options. At least
you won't find this one outside of a conformance test though.

 

[CBFalconer]

.... snip ...

The type of "abc" according to the standard is char[4], not const
char[4]. And the type of &"abc" is char(*)[4], not const char(*)[4].
There is no implicit conversion from char(*)[4] to const char(*)[4],
so Ben's code violates a constraint. And if you make the code

void f(char (*cp)[4]);
void g(void) { f(&"abc"); }

then the code is correct, no constraint is violated, and gcc will
accept the code, but it will emit a very misleading diagnostic
strongly suggesting the code is incorrect.

Admittedly a stretch, but you can even get gcc to reject valid code
with your options:

void f(void) { *"" = 0; }

This is allowed in a strictly conforming program as long as f is
never called, yet gcc will issue a hard error for it with your
options. At least you won't find this one outside of a conformance
test though.

However I maintain that anyone trying to perform those operations
will write the following code, eliminating the confusing '&', and
which triggers nothing:

#include <stdio.h>
void f(const char *cp) {puts(cp);}

void g(void) {f("abc");}

int main (void) {g(); return 0;}

Admittedly, the option can cause misleading diagnostics, but the
code still compiles. What it does is warn me about writing to a
non-writable string. And the option is there because of the
historic status of non-writable strings.

 

[Ben Bacarisse]

Harald van D?k wrote:

There is no implicit conversion from char(*)[4] to const char(*)[4],
so Ben's code violates a constraint.

However I maintain that anyone trying to perform those operations
will write the following code, eliminating the confusing '&',

I don't see how that alters the argument. If a set of options make a
compiler non-conforming, then re-writing the code does not make it
conforming.

With the code I posted, the options you suggest make gcc
non-conforming and you can't just re-write the parameter type and the
call to eliminate "the confusing &" without making the code quite
different.

Admittedly, the option can cause misleading diagnostics, but the
code still compiles.

And, in one case, fails to produce a required diagnostic.

What it does is warn me about writing to a
non-writable string. And the option is there because of the
historic status of non-writable strings.

Yes, it is a useful option but it is more useful if you know those
cases where it makes gcc non-conforming.

 

[Richard]

... snip ...

The type of "abc" according to the standard is char[4], not const
char[4]. And the type of &"abc" is char(*)[4], not const char(*)[4].
There is no implicit conversion from char(*)[4] to const char(*)[4],
so Ben's code violates a constraint. And if you make the code

void f(char (*cp)[4]);
void g(void) { f(&"abc"); }

then the code is correct, no constraint is violated, and gcc will
accept the code, but it will emit a very misleading diagnostic
strongly suggesting the code is incorrect.

Admittedly a stretch, but you can even get gcc to reject valid code
with your options:

void f(void) { *"" = 0; }

This is allowed in a strictly conforming program as long as f is
never called, yet gcc will issue a hard error for it with your
options. At least you won't find this one outside of a conformance
test though.

However I maintain that anyone trying to perform those operations
will write the following code, eliminating the confusing '&', and

And now the illustrious Chuck, having been schooled in gcc command line
options, proceeds to tell us how others will write their code!

Only in c.l.c

Reading a few Heathfield and Chuckster threads on a hot summer's evening
leaves me puffing from laughter! The arrogance! The egos! Wonderful
entertainment.

And for real C schooling one can read the rest.

which triggers nothing:

#include <stdio.h>
void f(const char *cp) {puts(cp);}

void g(void) {f("abc");}

int main (void) {g(); return 0;}

Admittedly, the option can cause misleading diagnostics, but the
code still compiles. What it does is warn me about writing to a
non-writable string. And the option is there because of the
historic status of non-writable strings.

--

 

[Chris Dollin]

Happily. In fact, here are five.

As Richard Heathfield observes elsethread, not one of your examples
fits the claim you made. Such transparent failure is its own reward.