error

[Barry Schwarz]

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.

 

[Casey Carter]

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.

 

[Bill Cunningham]

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

 

[Les Cargill]

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 "

 

[Keith Thompson]

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?

 

[army1987]

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().

 

[army1987]

#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.)

 

[Keith Thompson]

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. }

 

[Bill Cunningham]

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


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