Re: newbie question

From: name (user_at_host.domain)
Date: 08/14/04 

Date: Sat, 14 Aug 2004 18:25:11 -0000

On 2004-08-14, Default User <first.last@boeing.com.invalid> wrote:
> name wrote:
>
> Neither of the two commented out assignments would be correct. In first,
> you are assigning one uninitialized character from buf1 to an int
> pointer. That's not what you want.
>
> The second assigns a pointer to an array 1000 of char to an int pointer.
> That's a pointer type mismatch. Not what you want.
>
> If pbuf1 and pbuf2 were char * types, then you could assign to them like
> so:
>
> char *pbuf1;
> char *pbuf2;
>
> pbuf1 = buf1;
> pbuf2 = buf2;

Yep, I got that they were both wrong, and your explanation clarifies gcc's
somewhat laconic comments (laconic only to dummy's like moi... <grin>).

An uniinitialized character, eh? I thought that a pointer to an array
"decayed" into the address of the.... umm, yes. Perhaps the address, but
not the character indexed therein, so maybe pbuf1 = &buf[0] would make more
sense but be utterly useless in any case.

And the second mismatch.. pointer to an array of char doesn't work without
type cast when assigned to an int pointer? Duhhh... LOL!!!! Gawd, when
will I learn to understand the simple sense of what I read?!?

I need a teacher!!! <sigh>

>
>> Note that I've got pointers to the arrays included but commented out,
>> because I can't seem to understand a) why they are needed, and b) how to do
>> that assignment.
>
> See above for the how. The why is usually to use increment operations,
> which you can't do with an array.
>
> buf1++; /* NO!! */
> pbuf1++ /* Sure! */

Oh yes, got that. buf1 would be the entire array itself, right? Can't
increment an entire array, what would one increment it to?

>> What I thought I understood was that what was passed to the function
>> wordwrap were dereferenced pointers, so that what was going in and out were
>> the characters in the files, and not the addresses thereof.
>
> Errr, what? What you pass are the file pointers, which are pointers to
> an implementation-defined struct of type FILE. When used with the stdio
> file functions, you can read or write data from/to the associated files
> (assuming these pointers represent correctly opened files). There's no
> dereferencing going in.

Yes, I understand that the pointers are passed, but my understanding was
that the pointers were dereferenced when accessed, so that one got the data
that was being pointed to, and not the pointer itself. Implementation
defined struct of type FILE makes sense, and that's what the stdio library
handles, amongst other things.

Let's see if I've got this right: Initializing a pointer, "int *pvariable;";
assigning (referencing?) a pointer, "pvariable = &variable;"; dereferencing a
pointer, "variable = *pvariable;".

Which means that the pointers are passed, and stdio does its magic, and out
pops the data. Thus they are dereferenced within stdio? Guess I've got a
lot to learn now that I've been shown just how much I don't know... <grin>

>> And so I
>> thought that I should be able to read them directly, assign them to an
>> array, manipulate them whilst passing them to another array, and read the
>> second array out to the second file.
>
> Sounds ok.
>
>> I used the getc and putc routines used in the K&R2 example in chapter 1. I
>> did so becaue the filecopy routine drops right in place of wordwrap and the
>> second file is identical to the first. Which is why I figured I could at
>> least use them to read into the first array and out of the seond.
>>
>> That function is:
>>
>> void filecopy(FILE *ifp, FILE *ofp)
>> {
>> int c;
>>
>> while ((c=getc(ifp)) != EOF)
>> putc(c, ofp);
>> }
>
> Looks ok, a basic filecopy. Probably not the most efficient, but should
> work.

Straight out of K&R2, and they call the 'while' loop probably *the* most
basic C idiom. Retained that, if little else from my first study.. lol!!

>> So I thought I could build on that for 'wordwrap'. Wrong (?)
>
> Hard to say.

I think I can with some modifications. It works just fine with stdin and
stdout, so I should be able to hook it in here, I would think. However,
already I see how that could be simplified rather easily....

>> The code compiled (without the array pointers that are commented out). But
>> note the printf right after the assignment of input to the first array.
>> What comes out of that are graphical characters I don't understand. Without
>> that printf statement, the code compiles, but does nothing. The second file
>> is empty.
>
> You mean this part here, I think:
>
> for(i = 0; i < 1000; ++i)
> {
> while ((c=getc(ifp)) != EOF)
> buf1[i] = c;
> printf("%c", buf1[i]);
> }

Yep!

> You have loop problems. Look at your while loop. When does i get
> incremented? By the outer loop. Where is the data read? Inner loop. What
> happens is that the whole file get stuffed into buf1[0] (first outer
> loop pass). After that, each successive outer loop pass increments i,
> but no data is read in because ifp is already at EOF.
>
> Get rid of the inner loop, combining the two:
>
> for(i = 0; i < 1000 && (c=getc(ifp)) != EOF; ++i)
> {
> buf1[i] = c;
> printf("%c", buf1[i]);
> }
>
The cold hard light of day dawns. A while loop inside a for loop? ARGH!!
That should have been obvious! Yep, if(i == 1) buf1[i] == (one past EOF!).

And of course when I made the change, the original file came tumbling out,
at least up to the 1000th character. Gonna probably change that to INT_MAX.

I think I probably understand more than I feared I did, but with egregious
holes capable of passing Flights of Nasal Daemons! The devil is in the
details, of course, and that's a lot of what lurks in the holes. Simply
have to write lots of code, and then write lots more. Right?

> Brian Rodenborn

Thank you, Brian! Your reply was as pleasant and as thorough as I could
possibly want, and if (when?) I have further questions, I will look forward
to your responses!

Thanks again... 

-- 
Email is wtallman at olypen dot com

Relevant Pages

  • Re: char **argv & char *argv[]
    ... "pointer to pointer to char". ... >> pointer)) pointing to the first element of an array. ... so we have to start adding more context. ... type "pointer to char", rather than "array MISSING_SIZE of char". ...
    (comp.lang.c)
  • Re: why one array continues to grow after repeated call
    ... but it's really a method call to the array which a happens to be ... referencing at the time." ... assignment works as expected (or at least as most of us expect, ... 'a' is a pointer to the memory containing the ...
    (comp.lang.ruby)
  • Re: AMPC 1.4.3 released (C to Java Class Files compiler suite)
    ... array indexing in the JVM wouldn't be able to take advantage of the ... into the array each time thru the loop. ... using pointer arithmetic. ...
    (comp.compilers)
  • Re: why cannot assign to function call
    ... hypothetical C-like languages, ... sizeof business would still indicate that a pointer was being passed. ... talk about variables of an array type. ... the earlier version of the standard didn't have numbered ...
    (comp.lang.python)
  • Re: Code comments solicited
    ... A decrementing loop is reasonably well understood, ... pointer to an array of pointers to functions, ... pointer to a function that returns an array of int's, ... counter unless you have a specific reason to do otherwise, ...
    (comp.lang.cpp)