«

On Thu, 30 Aug 2012 18:57:53 -0400, "Bill Cunningham"
<> wrote:

>Barry Schwarz wrote:
>
>> I see you have reverted back to your standard of making random guesses
>> at both the problem and the solution. By now you should know it is
>> not effective.
>
>Guessed about what? "Let me try that." Wasn't a guess but a statement of
>fact.

Here is your statement I responded to which you trollishly decided to
snip:

> Wait a minute ! wait! Silly me. I have a file areadly called "a" and
>need to set the w to w+. Let me try that.

You guessed that opening the file in mode w somehow caused your seg
fault. You also guessed that w+ was the solution.

--
Remove del for email

On 2012-08-30 16:15, Bill Cunningham wrote:
> Casey Carter wrote:
>> On 2012-08-30 14:47, Bill Cunningham wrote:
>>> int main()
>>> {
>> [snip]
>>> nread = fread(buf, sizeof(buf), 1, fp);
>>
>> nread = fread(buf, 1, sizeof(buf), fp);
>>
>>> nwrite = fwrite(buf, sizeof(buf), nread, fp2);
>>
>> nwrite = fwrite(buf, 1, nread, fp2);
>
> You're right. That was part of the problem. Have I been reading this
> functions parameters backward. Why number of items 1 in fread?

Yes, you are reading the parameters backwards: your code is 1 element
with size sizeof(buf), my version is sizeof(buf) elements of size 1. I'm
guessing that your goal here is to copy the contents of one file to
another completely; your code will fail to do so if the size of the
source file is not an exact multiple of sizeof(buf) bytes. If there are,
e.g., 4000 bytes left to read in from fp, fread(buf, sizeof(buf), 1, fp)
will return 0 since it can't read _any_ elements of size 9000 from the
stream.

Casey Carter wrote:

> Yes, you are reading the parameters backwards: your code is 1 element
> with size sizeof(buf), my version is sizeof(buf) elements of size 1.
> I'm guessing that your goal here is to copy the contents of one file
> to another completely; your code will fail to do so if the size of the
> source file is not an exact multiple of sizeof(buf) bytes. If there
> are, e.g., 4000 bytes left to read in from fp, fread(buf,
> sizeof(buf), 1, fp) will return 0 since it can't read _any_ elements
> of size 9000 from the stream.

The jpeg was only 8178 or so byes long as reported by ls -la on my
system and printf showed that that was the number of bytes read. I set the
buffer size a little larger just so there would be extra room. I think the
reason that char buf[9000]={0}; didn't work was because the buffer was set
to zeros. At any rate decalring *and* initializing the buffer caused my
compiler to complain.

B

Bill Cunningham wrote:
<snip>

Consider the following macro:

#define trace() printf("%s,%d\n",__FILE__,__LINE__); fflush(stdout);

It's a bit brute force, but I leave this construct in production code
( along with the appropriate "calls" to trace() )

#define trace() printf("%s,%d\n",__FILE__,__LINE__); fflush(stdout);
#ifndef _TRACING_YES_
#undef trace
#define trace()
#endif

then compile with -D_TRACING_YES_ to turn on all the logging.

You'll know soon enough where it fails "

--
Les Cargill

"Bill Cunningham" <> writes:
[...]
> I set the
> buffer size a little larger just so there would be extra room. I think the
> reason that char buf[9000]={0}; didn't work was because the buffer was set
> to zeros. At any rate decalring *and* initializing the buffer caused my
> compiler to complain.

Based on the code you posted and on what you've said so far, I
think it's vanishingly unlikely that "declaring *and* initializing
the buffer" would cause problems, much less cause your compiler
to complain.

Your original code had:

char buf[9000] = {0};

is a perfectly valid decalaration which declares and initializes the
buffer. You said that program resulted in a seg fault, which implies
that it compiled. You said nothing about any compile-time warnings.

Would you like to try explaining again what you meant?

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Thu, 30 Aug 2012 14:23:47 -0700, Keith Thompson wrote:

> Casey Carter <> writes:
>> On 2012-08-30 14:47, Bill Cunningham wrote:
>>> int main()
>>> {
>> [snip]
>>> nread = fread(buf, sizeof(buf), 1, fp);
>>
>> nread = fread(buf, 1, sizeof(buf), fp);
>>
>>> nwrite = fwrite(buf, sizeof(buf), nread, fp2);
>>
>> nwrite = fwrite(buf, 1, nread, fp2);
>
> The ordering of the second and third arguments to fread() and fwrite()
> affects the value returned (because it's counting different things), but
> not how much they attempt to read or write.
>
> Since the program doesn't do anything with the results (other than
> printing them), it probably doesn't matter much.

It does ues the result of fread() to decide how much to fwrite().



--
[ T H I S S P A C E I S F O R R E N T ]
Troppo poca cultura ci rende ignoranti, troppa ci rende folli.
-- fathermckenzie di it.cultura.linguistica.italiano
<http://xkcd.com/397/>

On Fri, 31 Aug 2012 20:43:18 -0500, Les Cargill wrote:

> #define trace() printf("%s,%d\n",__FILE__,__LINE__); fflush(stdout);
> #ifndef _TRACING_YES_
> #undef trace
> #define trace()
> #endif

What would be wrong with

#ifdef _TRACING_YES_
#define trace() printf("%s,%d\n",__FILE__,__LINE__); fflush(stdout);
#else
#define trace()
#endif

?

(Also, I don't like macros that don't expand to expressions, so I'd
personally use

#ifdef TRACING_YES_
#define trace() (printf("%s,%d\n",__FILE__,__LINE__), fflush(stdout))
#else
#define trace() 0
#endif

and add a semicolon after it when I call it. Otherwise it could cause
trouble if used in the wrong place.)


--
[ T H I S S P A C E I S F O R R E N T ]
Troppo poca cultura ci rende ignoranti, troppa ci rende folli.
-- fathermckenzie di it.cultura.linguistica.italiano
<http://xkcd.com/397/>

army1987 <> writes:
> On Thu, 30 Aug 2012 14:23:47 -0700, Keith Thompson wrote:
>> Casey Carter <> writes:
>>> On 2012-08-30 14:47, Bill Cunningham wrote:
>>>> int main()
>>>> {
>>> [snip]
>>>> nread = fread(buf, sizeof(buf), 1, fp);
>>>
>>> nread = fread(buf, 1, sizeof(buf), fp);
>>>
>>>> nwrite = fwrite(buf, sizeof(buf), nread, fp2);
>>>
>>> nwrite = fwrite(buf, 1, nread, fp2);
>>
>> The ordering of the second and third arguments to fread() and fwrite()
>> affects the value returned (because it's counting different things), but
>> not how much they attempt to read or write.
>>
>> Since the program doesn't do anything with the results (other than
>> printing them), it probably doesn't matter much.
>
> It does ues the result of fread() to decide how much to fwrite().

So it does. My mistake. I should stop making those. }

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Barry Schwarz wrote:
> Here is your statement I responded to which you trollishly decided to
> snip:
>
>> Wait a minute ! wait! Silly me. I have a file areadly called "a"
>> and need to set the w to w+. Let me try that.
>
> You guessed that opening the file in mode w somehow caused your seg
> fault. You also guessed that w+ was the solution.

Oh I see. Well I now know w and w+ doesn't make any difference.

Bill