Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!mit.eternal-september.org!.POSTED!not-for-mail From: Hadron Quark Newsgroups: comp.os.linux.advocacy Subject: Re: Elizabeth Warren 1/1024 Native American Date: Fri, 19 Oct 2018 19:16:26 +0200 Organization: turdv owners club Lines: 189 Message-ID: <87d0s5dfh1.fsf@gmail.com> References: <7b39071c-0898-4575-8799-76f04f683d52@googlegroups.com> <75645a72-f0d2-44da-bc48-d47fab4c83ea@googlegroups.com> <448e03ca-7540-4fb0-aa0c-c00f40659161@googlegroups.com> <45823d69-6dbd-4760-aefc-dba729c059f5@googlegroups.com> <9z0808bz0b.3ga8@rooftop.invalid> <9a08b8083a.a3@rooftop.invalid> <3e1a636c-736a-49c3-8ed2-eed3017f0cc3@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mit.eternal-september.org; posting-host="a5bb839aa27b9467889d243ff11b3889"; logging-data="10539"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+WlaucJkD/cfpiIqXT90ue762mEwVjwxw=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) Cancel-Lock: sha1:+sYr7qedkM20gGoGKMTzKG6GXe0= sha1:L3M0xoR3R2b0nxcoxcRcZ1PB7O4= Xref: csiph.com comp.os.linux.advocacy:472768 Steve Carroll writes: > On Thursday, October 18, 2018 at 4:32:37 PM UTC-6, owl wrote: >> owl wrote: >> > Steve Carroll wrote: >> >> On Thursday, October 18, 2018 at 12:25:21 PM UTC-6, owl wrote: >> >>> Steve Carroll wrote: >> >>> > On Thursday, October 18, 2018 at 11:54:42 AM UTC-6, owl wrote: >> >>> >> Steve Carroll wrote: >> >>> >> > On Wednesday, October 17, 2018 at 2:46:27 PM UTC-6, owl wrote: >> >>> >> >> Steve Carroll wrote: >> >>> >> > >> >>> >> > (snip) >> >>> >> > >> >>> >> >> >> x is never anything but a pointer. >> >>> >> >> > >> >>> >> >> > But it can still hold a value. >> >>> >> >> >> >>> >> >> >> >>> >> >> An address value. >> >>> >> > >> >>> >> > I know that a var is just a place in memory that holds a value so, in this >> >>> >> > respect, it's a pointer. But why complicate things with this additional >> >>> >> > pointer keyword? Why the need to refer to the first char at all? >> >>> >> > >> >>> >> >> > For example, when I also run this with the above, >> >>> >> >> > and placed above it... >> >>> >> >> > >> >>> >> >> > char *p = "test"; >> >>> >> >> > char b[] = "test"; >> >>> >> >> > printf("%c\n",*p); >> >>> >> >> > printf("%s\n",b); >> >>> >> >> > >> >>> >> >> > I get a value for *p: 't'... the first char of the array, like you said earlier. >> >>> >> >> > >> >>> >> >> >> >>> >> >> p and *p are different things. p is the address. *p is the char at >> >>> >> >> that address. >> >>> >> > >> >>> >> > What I initially didn't realize (because it failed on a first run!) was this... >> >>> >> > >> >>> >> > char *p = "test"; >> >>> >> > >> >>> >> > ... is simultaneously assigning the value "test to the variable 'p' and >> >>> >> > creating a pointer to it (the first char). So this will display both : >> >>> >> > >> >>> >> > char *p = "test"; >> >>> >> > printf("%c\n",*p); >> >>> >> > printf("%s\n",p); >> >>> >> > >> >>> >> > In any event, I get back 't' and then the entire string "test", which is, to >> >>> >> > my way of thinking, a value, not an "address". I also noticed a pointer >> >>> >> > has to be defined in advance, this... >> >>> >> > >> >>> >> > char p = "test"; >> >>> >> > printf("%c\n",*p); >> >>> >> > >> >>> >> > ... won't work, which seems odd to me. Maybe it's due to the fact that >> >>> >> > you won't always need a pointer? However, if you do decide to create >> >>> >> > one you can assign a value to the 'pointed to' variable simultaneously, >> >>> >> > which is handy. >> >>> >> > >> >>> >> >> a %s printf would print that char and all successive >> >>> >> >> chars until it hits a '\0'. >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> > webdev$ ./test >> >>> >> >> > t >> >>> >> >> > test >> >>> >> >> > (null) >> >>> >> >> > hello >> >>> >> >> > hello >> >>> >> >> > >> >>> >> >> > One strange thing, this time, just by adding the new lines, instead of a blank >> >>> >> >> > line I got: '(null)'. >> >>> >> >> >> >>> >> >> Like I said, x is null at that point. >> >>> >> > >> >>> >> > I got it, but it didn't display null the first time through, just a blank line, >> >>> >> > which was a little confusing. >> >>> >> > >> >>> >> >> When I run it, with the your new code placed above the old, the first >> >>> >> >> thing that happens with stdout is the attempt to >> >>> >> >> >> >>> >> >> printf("%c\n",x); >> >>> >> >> >> >>> >> >> when x has not yet been assigned a value. That is an attempt to >> >>> >> >> print (as a char) the null pointer x. >> >>> >> > >> >>> >> > As I assume most of us do, I often learn more by trying to break things, >> >>> >> > code that runs differently on the first run slows things down a bit. What >> >>> >> > causes that? >> >>> >> > >> >>> >> >> >>> >> When trying to grasp pointers, you have to get away from the concept of >> >>> >> strings. Pointers are addresses. Period. >> >>> > >> >>> > From what I've read they're 'named' addresses so, like you show below, a >> >>> > pointer named 'p' represents some numeric address (i.e. 0x7ffc9f9f81e8). >> >>> > >> >>> >> >>> That is the address of p itself, not the address that p holds. >> >> >> >> Like you said in your other post, 'p' holds a byte address (i.e. 0x4006e8) which >> >> is where 't' is stored. This makes sense and thanks to your other post about >> >> printf doing what it does (yes, I know, you ran that past me several times but I >> >> didn't understand) from the pointer on out... things are a bit more clear. >> >> >> >>> (See the code at the bottom). >> >> >> >> I've seen this, or similar, but I gotta study on these operators: >> >> char *c=(char *)&x; >> >> >> > >> > There x is an int (a 4-byte value). The code casts the address of the >> > int to a char pointer, so you can walk the bytes of the int. >> > >> >> You could also walk the ints themselves, with the int pointer, >> and shift bits to isolate bytes: >> >> #include >> #include >> >> #define INTCOUNT 10 >> >> int main(void) >> { >> int *ip; >> int i=0; >> >> ip=malloc(INTCOUNT * sizeof *ip); >> if(ip==NULL) >> { >> fprintf(stderr,"ip malloc failed\n"); >> exit(1); >> } >> >> ip[0]=0x41424344; >> ip[1]=0x45464748; >> ip[2]=0x494a4b4c; >> ip[3]=0x4d4e4f50; >> ip[4]=0x21222324; >> ip[5]=0x25262728; >> ip[6]=0x292a2b2c; >> ip[7]=0x2d2e2f30; >> ip[8]=0x31323334; >> ip[9]=0x35363738; >> >> for(i=0;i> { >> printf("%c",ip[i]>>24); >> printf("%c",ip[i]<<8>>24); >> printf("%c",ip[i]<<16>>24); >> printf("%c",ip[i]<<24>>24); >> } >> printf("\n"); >> >> free(ip); >> return 0; >> } > > I've been reading from that site you gave me a link to, which is helping. > Thanks for all this stuff you're posting, too. It may take awhile 'cuz I don't > have a lot of time right now but I'll get better. Array name and pointer interchangeable in C. ,---- | int arrInts[10]; `---- You can then use sizeof() if you want to be 1337 and confuse people.. ,---- | elements= sizeof(arrInts) / sizeof(arrInts[0]) `---- But do NOT use sizeof if you pass your array (pointer) to a functions.... sizeof(p) will be the sizeof of the int * pointer. -- chrisv alias turdv is a turd