Re: size of a sizeof(pointer)
From: Michael Wojcik (mwojcik_at_newsguy.com)
Date: 02/16/04
- Next message: Michael Wojcik: "Re: size of a sizeof(pointer)"
- Previous message: javuchi: "Re: vi rules"
- In reply to: Malcolm: "Re: size of a sizeof(pointer)"
- Next in thread: Malcolm: "Re: size of a sizeof(pointer)"
- Reply: Malcolm: "Re: size of a sizeof(pointer)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 16 Feb 2004 16:19:13 GMT
In article <c0kqm9$bp4$1@newsg2.svr.pol.co.uk>, "Malcolm" <malcolm@55bank.freeserve.co.uk> writes:
>
> "Michael Wojcik" <mwojcik@newsguy.com> wrote in message
> >
> > > This really is the exception that proves the point.
> >
> > That's not what that idiom means.
>
> Etymology isn't meaning. The proverb is not used in that way.
It is by some of us. And I'm well aware of how language works,
thanks. I was simply hoping to point out that you were employing a
bogus argument through an unfortunately popular turn of phrase,
apparently under the misapprehension that its common misuse made it
logically valid. Now it appears that you are simply unable to
understand that it's a bogus argument.
> (By the way the etymology itself is dodgy)
> http://www.icsi.berkeley.edu/~nchang/personal/exception.html
Few things are crystal-clear in English etymology. The fact that
Nancy Chang happened upon one philologist who happened to think that
the phrase originally employed "prove" in the sense of "test" does
little to contradict the evaluations of more authoritive sources,
which agree with Bergen rather than Breen. And, frankly, I don't
see much validity to Breen's argument; derivation from German rather
than Latin does nothing to demonstrate that "prove" should be used
in the sense of "test".
> It's not something in formal logic, but a rule of thumb.
Ah, my favorite form of argument. "It's not logical, just something
that's often kinda sorta right."
> To see if a rule
> applies, look at cases that appear to be exceptions.
That process falls quite nicely under logic. It's called "trying
to prove the thesis by negation of the converse". Unfortunately
for your argument, what it proves is that the converse is false.
Your examples don't demonstrate anything except the difference
between a universal rule and a general one. I fail to see how that's
germane to the argument, which is whether the various C implementa-
tions for the AS/400 are a counterexample to the thesis that "no C
implementations provide safe pointers". At least one exception
exists; the thesis is phrased as a universal rule and so is disproven.
Now, apparently, you want to convert this thesis into a general rule
("few C implementations provide safe pointers"), but since this is
an unremarkable statement, you hope to salvage its force by relegating
its exceptions to some second-class status. It's barely a step beyond
argument-by-sticking-one's-fingers-in-one's-ears.
> > Really. Care to expand upon this rather bizarre thesis? In what
> > way do the characteristics of the AS/400 1) make C any less "ideal"
> > there than on any other platform, or 2) require automatic memory
> > management?
>
> Because C sacrifices safety in memory access for efficiency.
Chapter and verse, please. (Oh, I realize this is standard C lore.
But the language does not *depend* on this trade-off, and it has
many admirable qualities which have nothing to do with it.)
> Since the
> platform won't allow this, the safety has to be put in at an inappropriate
> level. So I would guess that when writing a function to iterate over a
> string, the pointer is checked for out-of-bounds at every increment.
Your guess would be wrong, in the general case.
> Certainly passing a pointer, if it contains validity information, will be
> very slow.
Pointers in the various AS/400 C implementations are 16 bytes long.
Why should passing such an object be "very slow"?
> There ceases to be a point in using C on the AS/400, except that C is a very
> popular language, and there is always a point in supporting a standard.
The presence of (at least) three commercial C implementations for the
AS/400, and AS/400 software developed using them, suggests that a
significant number of people disagree with this claim as well.
> A
> bit like driving a sports car over a traffic-calmed road - it can't go very
> fast and a hatchback would make more sense, but if you own a sports car
> already then you might want to do it.
So your contention is that C is a sensible language to use only on
platforms where it can be used in a dangerous mannner? Perhaps we
should take a little c.l.c poll. How many people here use C because
it lets you do unsafe things?
--
Michael Wojcik michael.wojcik@microfocus.com
Not the author (with K.Ravichandran and T.Rick Fletcher) of "Mode specific
chemistry of HS + N{_2}O(n,1,0) using stimulated Raman excitation".
- Next message: Michael Wojcik: "Re: size of a sizeof(pointer)"
- Previous message: javuchi: "Re: vi rules"
- In reply to: Malcolm: "Re: size of a sizeof(pointer)"
- Next in thread: Malcolm: "Re: size of a sizeof(pointer)"
- Reply: Malcolm: "Re: size of a sizeof(pointer)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
