Re: Is argv array modifiable ?

bluejack wrote:
Peter Nilsson wrote: 
That is a naive, even dangerous, form of reasoning. C has many quirks
which are counter-intuitive. Some of them are far from sensisble, e.g.
gets.

Granted.

These quirks won't be learnt by trial and error. The *most* you will learn is how the specific version of the specific implementation you are using works.

Trusting (or blaming) the Committee is an irrelevance. At the end of
the day, the language is that written in the Standard. It is up to
programmers to educate themselves on what that language is.


And, while there are several good approaches to educating yourself
on what the language is ... and I realize this is going to endear me
to nobody ... my preferred method is "trial and error" -- despite my
"naive and dangerous" form of reasoning, it's a perfectly effective
approach,

No, it is most definitely NOT a perfectly effective method. All sorts of things that you might think are correct, and might work on your compiler this week, might fail abysmally when it actually matters to you.

> assuming you start out by trusting nobody.

Start by not trusting trial and error, because it has been repeatedly been shown that the people posting here having relied on it to learn C have learnt to do things which are definitely wrong.

> I don't trust 
the standard (in part because there's no guarantee it has been
implemented correctly,

In that case build your own chip factory, design and build your own chips, and write your own compiler.

> but mostly because I don't have a copy),

Google for n1124.pdf to get a free public draft of the next version, or buy a copy of the current version from a standards body (you can get it for $18 last I heard).

I don't trust compiler designers (because they don't necessarily
implement correctly),

In that case don't use any you have not implemented. You also can't trust assemblers, text editors or the OS by that reasoning.

> I don't trust secondary documentation (it's
like a photocopy of a photocopy),

It is easy to find reviews of books to see if they are reliable, and you can cross-reference to the standard if you are not sure.

> I *certainly* don't trust usenet,
and I trust my own memory *least of all*.

> What I trust are demonstrable
results.

I can demonstrate with one compiler that you can safely modify string literals and get the expected result. I can also demonstrate with a later version of the *same* compiler that you can't modify string literals because it causes a SIGSEGV (I might be wrong on the exact signal, but definitely a crash). The reality is that anything can happen because it is undefined behaviour. However, had I relied on your method of trial and error all my code could have suddenly gone from "working" to "crashing".

If I could be bothered I could come up with lots of other examples, but the above is one I know to be demonstrably true.

Naturally, with that mentality, I tend to code defensively.

Coding defensively REQUIRES understanding how the language is DEFINED to work, what you are doing by relying on trial and error rather than a reliable source of information is coding stupidly.

> It would 
never
even occur to me to *want* to change argv (or use gets). Still I do
find
these conversations fascinating, and I always enjoy the cranky
attitude found on usenet!

Well, if you think trial and error is a substitute for a good text book expect responses a lot more cranky than mine.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
.

Relevant Pages

  • Re: Encrypting/Decrypting Password from a Config File
    ... >> That assumes you trust the compiler. ... even if each of the individual components behave exactly ... And there's still the issue of trusting your own senses. ...
    (comp.lang.java.programmer)
  • Re: Encrypting/Decrypting Password from a Config File
    ... US code breakers broke a one time pad because they found it ... That assumes you trust the compiler. ... So your best bet is to build a read-only USB key from scratch, ...
    (comp.lang.java.programmer)
  • Re: Attn: Apoptygma, I offer a compromise
    ... of someone they can trust might be this. ... Elwynn was created by an eight year old niece that loved to run around ... English language. ... If you go outside of Elwynn you will die 'because you are too young' ...
    (alt.games.warcraft)
  • Re: [Lit.] Buffer overruns
    ... If you think the library in question does not suit your needs, ... You are wrong when you say it is not a language or library ... Doing so would be bad design at the front of the project. ... trust the library, trust the linker, trust the program loader, trust the OS. ...
    (sci.crypt)
  • Attn: Apoptygma, I offer a compromise
    ... The reason I am not appalled by youngsters playing WoW under supervision ... of someone they can trust might be this. ... Elwynn was created by an eight year old niece that loved to run around ... English language. ...
    (alt.games.warcraft)