«

On Dec 19, 9:47*pm, 88888 Dihedral <dihedral88...@googlemail.com>
wrote:
> On Tuesday, December 20, 2011 2:38:58 AM UTC+8, John Tsiombikas wrote:
> > On 2011-12-19, 88888 Dihedral <dihedr...@googlemail.com> wrote:
>
> > > In a virtual memory system of a descent OS,
> > > there's no studpid checking in the ap level.
>
> > What is the ap level?
> > All virtual memory systems I'm aware of use page-level protection at
> > least. That is, invalid accesses to unmapped or protected pages are
> > trapped by the system and are used to either kill the application or
> > perform demand paging.
>
> > > But if someone is writing AP in the real memory of some machine,
> > > it is still no need to check in C in the release version by a professional
> > > programmer.
>
> > I don't see how writing code as a profession or as a hobby has anything
> > to do with this.
>
> Writing code as a hobby is good toward a professional programmer.

not if they take a "this is only a hobby so quality doesn't matter"
attitude. Pretty soon hobby attitudes leak through to professional
programs. What sort of hobby is it where you don't care?

> Many engineers just write programs in the open source of sourceforge site
> for fun.

and they write ****?

Nick Keighleyæ–¼ 2011å¹´12月28日星期三UTC+8下å�ˆ6時58分40ç§ ’寫é�“：
> On Dec 19, 9:47Â*pm, 88888 Dihedral <dihedr...@googlemail.com>
> wrote:
> > On Tuesday, December 20, 2011 2:38:58 AM UTC+8, John Tsiombikas wrote:
> > > On 2011-12-19, 88888 Dihedral <dihe...@googlemail.com> wrote:
> >
> > > > In a virtual memory system of a descent OS,
> > > > there's no studpid checking in the ap level.
> >
> > > What is the ap level?
> > > All virtual memory systems I'm aware of use page-level protection at
> > > least. That is, invalid accesses to unmapped or protected pages are
> > > trapped by the system and are used to either kill the application or
> > > perform demand paging.
> >
> > > > But if someone is writing AP in the real memory of some machine,
> > > > it is still no need to check in C in the release version by a professional
> > > > programmer.
> >
> > > I don't see how writing code as a profession or as a hobby has anything
> > > to do with this.
> >
> > Writing code as a hobby is good toward a professional programmer.
>
> not if they take a "this is only a hobby so quality doesn't matter"
> attitude. Pretty soon hobby attitudes leak through to professional
> programs. What sort of hobby is it where you don't care?
>
> > Many engineers just write programs in the open source of sourceforge site
> > for fun.
>
> and they write ****?

Not really at all, some are experiments and some are excellent.

Nowadays programmers can sharpen their programming skills very fast in the
open source projects. I remembered in the old days of workstations and mainframes. One had to pay service fees for those vendors of trivial settings
from time to time after installing new software packages that conflicted
some packages installed.

ralph <> writes:
<snip>
> The concepts behind ...
>
> datatype arr[i] ~== *(arr + ( i * sizeof(datatype)))
>
> ... and understanding the difference between addresses and pointer
> datatypes has served to untangle a ton of "pointer" questions. But
> that's me, and my students, and it doesn't matter. ...

That suggests you've only had to untangle such questions in relatively
simple situations. As I pointed out before, i*sizeof(datatype) is
sometimes the wrong thing to add to the address. But you can explain
all of this without leaving the world of C's pointers:

arr[i] is *(arr + i)

which means (at a lower level)

(int *)((char *)arr + i * sizeof *arr)

As soon as you try to move beyond C's abstract pointers you need to
start talking about machine addresses and these can be more subtle than
your equation assumes them to be.

<snip>
--
Ben.

On 12/27/2011 09:09 PM, ralph wrote:
> On Tue, 27 Dec 2011 15:08:05 -0800, Keith Thompson <kst->
> wrote:
>
>
>>
>> I get the impression that you're yielding on this point because of the
>> number of people who disagree with you. I'd prefer to think that you
>> understand the argument we're making. (If you change your mind, we'll
>> *all* be right!)
>>
>> Or maybe I'm just beating a dead horse.
>>
>
> For the moment yes, that is exactly what I'm (we're) doing. ha
>
> I think I understand what you are trying to say, at least recognize
> the "C-Legalese", but unable to distinguish the subtleties in
> difference between what I'm saying and what you guys are saying.

It's not C legalese, and it's not subtle. It's a fundamental point about
how C pointer arithmetic works that must be properly understood by any C
programmer before he's competent to write any serious code.

> [I mean, (among other things), as long as anyone refers to the "arr"
> in an array declaration as a "pointer" when it is obviously a literal
> constant - I'm likely to stay confused.]

It's not a pointer in the declaration that we're talking about. However,
in most expressions involving the name of an array, it's name is
automatically converted to a pointer to the first element of the array.
--
James Kuyper

On Saturday, December 17, 2011 10:34:20 PM UTC-6, ralph wrote:
> On Sun, 18 Dec 2011 01:26:59 +0000, Ben Bacarisse
> <ben.u...@bsb.me.uk> wrote:
>
[snip]

> >
> >It's not easy to explain the lower-level arithmetic without reference to
> >some particular machine. For example, on a machine with, say, byte and
> >word addresses, you can't describe it as you have done. By all means,
> >take a simple architecture and explain what a[0] means on one particular
> >system using addresses and size calculations, but you will also have to
> >explain, eventually, that arr[i] is, by definition, *(arr + i).
> >
>
> Sure it is because it ain't *(arr + i). It is ...
>
> *(arr + ( i * sizeof(datatype)))
>

I suggest you try that with some real code:

int a[] = {0,1,2,3,4,5};
printf("a[1] = %d, *(a + 1) = %d, *(a + 1 * sizeof *a) = %d\n",
a[1], *(a + 1), *(a + 1 * sizeof *a));

*(a + i * sizeof *a) != a[i]

Pointer arithmetic is defined in terms of the size of the pointed-to type; For any object of type pointer to T, the expression *(p + i) yields the value of the i'th *element* of type T after p, not the i'th *byte*.

> So for int arr[10];
> arr[5] is *(arr + (5 * sizeof(int)))
> byte arr[10];
> arr[5] is *(arr + (5 * sizeof(byte)))
>

Again, I suggest you write some code to test that assertion.

> You don't care what platform you are using because the sizeof takes
> care of it. sizeof and size of datatypes are defined for each compiler
> (which is platform specific by default). That's how pointer arithmetic
> works. That's how the C language achieves platform independence and
> compilers can be implemented for any specific architecture.


*EXACTLY*. You don't have to worry about the size of the data type, so you don't have to think in terms of *byte offsets*. You simply think in terms of *elements*.

Barry Schwarzæ–¼ 2011å¹´12月18日星期日UTC+8上å�ˆ2時10分09ç§ ’寫é�“：
> On Sat, 17 Dec 2011 08:51:33 -0800 (PST), 88888 Dihedral
> <dihedr...@googlemail.com> wrote:
>
> >On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
> >> hi
> >> my Q is on the c language tell me now why c has pointers.
> >> parshant
> >>
> >>
> >> --
> >> curixinfotech
> >> ------------------------------------------------------------------------
> >> curixinfotech's Profile: http://forums.yourdomain.com.au/member.php?userid=134
> >> View this thread: http://forums.yourdomain.com.au/showthread.php?t=3319
> >
> >OK, I'll explain how to use a pointer in C without any knowledge in the
> >hardware or assembly here.
> >//
> >int i;
> >int a[3]={ 1,2,3} ; // an array of 3 integers
> >int* ptr1; // Note the star should be right after int, not initialize
> >int* ptr2; // not initialized
> >
> >ptr1=a; // Read this as to make ptr1 to be an alias of a.
>
> If that were true, the sizeof(a) and sizeof(ptr1) would be equal\

Why do you care about the size of an array declared on the stack?

Everything on the stack is to be popped out in the exit of a function in C.

But a pointer allocated in the heap is different.



> which, in the general case, they are not. ptr1 is simply a pointer
> that points to the start of a. Even though they share some
> similarities in the language syntax, a pointer is a completely
> different type than an array. Calling one an alias of the other just
> breeds unnecessary confusion.

A pointer defines an alias to a variable. Don't you get it in C or assembly?

for some reason "Dihedral" has revived this ancient topic

On Jan 9, 11:48Â*pm, 88888 Dihedral <dihedral88...@googlemail.com>
wrote:
> Barry Schwarzæ–¼ 2011å¹´12月18日星期日UTC+8上å�ˆ2時10分09ç§ ’寫é�“：
> > On Sat, 17 Dec 2011 08:51:33 -0800 (PST), 88888 Dihedral
> > <dihedr...@googlemail.com> wrote:
> > >On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:


> > >> my Q is on the c language tell me now why c has pointers.

you never explained why you wanted to know this or what sort answer
would satisfy you.


> > >OK, I'll explain how to use a pointer in C without any knowledge in the
> > >hardware or assembly here.

and then you plummet into implementaion specifics like a fish into
water...

> > >int i;
> > >int a[3]={ 1,2,3} ; // an array of 3 integers
> > >int* ptr1; // Note the star should be right after int, not initialize

this is an opinion not a fact. It is quite common (more common?) for C
programmers to do the opposite of what you suggest.

> > >int* ptr2; // not initialized
>
> > >ptr1=a; // Read this as Â*to make ptr1 to be an alias of a.

no. Not really.

> > If that were true, the sizeof(a) and sizeof(ptr1) would be equal\

exactly. It also isn't an alias.

> Why do you care about the size of an array declared on the stack?

as usual dihedral inhabits a universe not co-terminus with our own.

becuase it might blow the stack? the point is 'ptr1' is NOT an alias
for 'a' because **they have different behaviour***

Also, how do you know these identifiers refer to automatic variables?
The indentation indicates otherwise.

> Everything on the stack is to be popped out in the exit of a function in C.

dihedral spouts irrelevence again

> But a pointer allocated in the heap is different.

why? The alias stuff nonsense no matter where they are allocated

> > which, in the general case, they are not. Â*ptr1 is simply a pointer
> > that points to the start of a. Â*Even though they share some
> > similarities in the language syntax, a pointer is a completely
> > different type than an array. Â*Calling one an alias of the other just
> > breeds unnecessary confusion.

yes

> A pointer defines an alias to a variable. Don't you get it in C or assembly?

just repeating nonsense doesn't make it true. Argument ad Goebbels

Nick Keighley於 2012年1月10日星期二UTC+8下�4時21分05秒 寫�：
> for some reason "Dihedral" has revived this ancient topic
>
> On Jan 9, 11:48Â*pm, 88888 Dihedral <dihedr...@googlemail.com>
> wrote:
> > Barry Schwarzæ–¼ 2011å¹´12月18日星期日UTC+8上å�ˆ2時10分09ç§ ’寫é�“：
> > > On Sat, 17 Dec 2011 08:51:33 -0800 (PST), 88888 Dihedral
> > > <dihe...@googlemail.com> wrote:
> > > >On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
>
>
> > > >> my Q is on the c language tell me now why c has pointers.
>
> you never explained why you wanted to know this or what sort answer
> would satisfy you.
>
>
> > > >OK, I'll explain how to use a pointer in C without any knowledge in the
> > > >hardware or assembly here.
>
> and then you plummet into implementaion specifics like a fish into
> water...
>
> > > >int i;
> > > >int a[3]={ 1,2,3} ; // an array of 3 integers
> > > >int* ptr1; // Note the star should be right after int, not initialize
>
> this is an opinion not a fact. It is quite common (more common?) for C
> programmers to do the opposite of what you suggest.
>
> > > >int* ptr2; // not initialized
> >
> > > >ptr1=a; // Read this as Â*to make ptr1 to be an alias of a.
>
> no. Not really.
>
> > > If that were true, the sizeof(a) and sizeof(ptr1) would be equal\
>
> exactly. It also isn't an alias.
>
> > Why do you care about the size of an array declared on the stack?
>
> as usual dihedral inhabits a universe not co-terminus with our own.
>
> becuase it might blow the stack? the point is 'ptr1' is NOT an alias
> for 'a' because **they have different behaviour***
>
> Also, how do you know these identifiers refer to automatic variables?
> The indentation indicates otherwise.
>
> > Everything on the stack is to be popped out in the exit of a function in C.
>
> dihedral spouts irrelevence again
>
> > But a pointer allocated in the heap is different.
>
> why? The alias stuff nonsense no matter where they are allocated
>
> > > which, in the general case, they are not. Â*ptr1 is simply a pointer
> > > that points to the start of a. Â*Even though they share some
> > > similarities in the language syntax, a pointer is a completely
> > > different type than an array. Â*Calling one an alias of the otherjust
> > > breeds unnecessary confusion.
>
> yes
>
> > A pointer defines an alias to a variable. Don't you get it in C or assembly?
>
> just repeating nonsense doesn't make it true. Argument ad Goebbels

I am not interested to argue with ASSEMBLY IDIOTS.