Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > code

Reply
 
 
Bill Cunningham
Guest
Posts: n/a
 
      09-03-2012
I worked and worked on this code until my compiler gave no more errors
even with -Wall -ansi turned on. So I think it's valid. The question is is
it doing what I want it to. I don't think so. Its never stopped and I've had
to interrupt it while running. I get a bunch of textual 00 all across the
screen. The idea is to take a binary and convert it to text and print it in
hex. I never get out of the do-while loop. Like a hex dump does but a hex
dump doesn't convert a binary into text. Is what I'm wanting valid? Am I
getting what I'm asking for. Here's the code if your reader lets you read it
neatly.

Bill
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
int buf[8200];
unsigned buf2[8200];
FILE *fp, *fp2;
if ((fp = fopen("6", "rb")) == NULL) {
perror("fopen 1");
exit(1);
}
if ((fp2 = fopen("b", "wt")) == NULL) {
perror("fopen 2");
exit(1);
}
do {
*buf = fscanf(fp, "%i", buf);
fprintf(fp2, "%i %x", *buf, *buf2);
}
while (*buf != EOF);
fclose(fp);
fclose(fp2);
printf(" %i %u", *buf, *buf2);
return 0;
}


 
Reply With Quote
 
 
 
 
Bill Cunningham
Guest
Posts: n/a
 
      09-03-2012
OH and the resulting text file is huge too.

Bill


 
Reply With Quote
 
 
 
 
Barry Schwarz
Guest
Posts: n/a
 
      09-03-2012
On Sun, 2 Sep 2012 22:50:37 -0400, "Bill Cunningham"
<(E-Mail Removed)> wrote:

> I worked and worked on this code until my compiler gave no more errors
>even with -Wall -ansi turned on. So I think it's valid. The question is is


Think again.

>it doing what I want it to. I don't think so. Its never stopped and I've had


See, upon reflection you can reach a correct conclusion.

>to interrupt it while running. I get a bunch of textual 00 all across the
>screen. The idea is to take a binary and convert it to text and print it in


Describe in detail what the input binary looks like.

>hex. I never get out of the do-while loop. Like a hex dump does but a hex


If you want to print it in hex, what is the %i doing in your print
format?

>dump doesn't convert a binary into text. Is what I'm wanting valid? Am I


Provide a short sample of input and what you want the output to look
like.

>getting what I'm asking for. Here's the code if your reader lets you read it
>neatly.
>
>Bill
>#include <stdio.h>
>#include <stdlib.h>
>
>int main(void)
>{
> int buf[8200];
> unsigned buf2[8200];


Where did these array sizes come from? What purpose did you want buf2
to serve?

> FILE *fp, *fp2;
> if ((fp = fopen("6", "rb")) == NULL) {
> perror("fopen 1");
> exit(1);
> }
> if ((fp2 = fopen("b", "wt")) == NULL) {
> perror("fopen 2");
> exit(1);
> }
> do {
> *buf = fscanf(fp, "%i", buf);


This statement says
Read a bunch of text characters from a stream and convert them to
an int value. (I have no idea if the fact that you opened the file as
binary will have any effect on this operation.) Store the int value
in the int object pointed to by buf. (Since buf is an array, this
expression is converted to &buf[0] which is a perfectly good int*.)
After this completes, store the number of successful conversions in
*buf (which is the same as buf[0]. So you completely erase the value
that fscanf obtained and proceed to store either 0, 1, or EOF in
buf[0].

Under the very risky assumption that the call to fscanf had a real
purpose, I submit to you that this code does not accomplish what you
want. It is now up to you to tell us in PRECISE DETAIL what you
intended this statement to accomplish.

By the way, you should always check that fscanf succeeded.

> fprintf(fp2, "%i %x", *buf, *buf2);


Since buf2 was never initialized with any values, all the elements of
the array are indeterminate. The act of evaluating indeterminate
values results in undefined behavior.

Since you don't specify any whitespace after the %x or before the %i,
whatever value is written for the %i for iteration n+1 will
immediately abut the value previously written for the %x on iteration
n. Something like
1 0x123456781 0x12345678...

> }


It's a shame you have reneged on your commitment to indent your code.

> while (*buf != EOF);
> fclose(fp);
> fclose(fp2);
> printf(" %i %u", *buf, *buf2);


All of buf2 is still indeterminate so this is also undefined.

> return 0;
>}
>


--
Remove del for email
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-03-2012
"Bill Cunningham" <(E-Mail Removed)> writes:
[...]
> The idea is to take a binary and convert it to text and print it in
> hex. I never get out of the do-while loop. Like a hex dump does but a hex
> dump doesn't convert a binary into text.


A hex dump *does* convert a binary into text. What did you think a hex
dump does?

[...]

> #include <stdio.h>
> #include <stdlib.h>
>
> int main(void)
> {
> int buf[8200];
> unsigned buf2[8200];
> FILE *fp, *fp2;
> if ((fp = fopen("6", "rb")) == NULL) {
> perror("fopen 1");
> exit(1);
> }


Your indentation is messed up. I suspect that you're indenting with
a mix of spaces and tabs, and the tabs are getting lost somewhere
between your news client and mine. Figure out how to indent with
spaces only, at least for code you post. (Filtering through the Unix
"expand" command is one way to do this.)

[...]

> do {
> *buf = fscanf(fp, "%i", buf);
> fprintf(fp2, "%i %x", *buf, *buf2);
> }
> while (*buf != EOF);


For a do-while loop, it's clearer to put the while on the same line as
the "}"; otherwise it looks very much like a while loop.

[...]

There are numerous other problems with your code.

As you should realize by now, just getting a C program to compile
doesn't imply that it's going to work. There are other languages
where code that just compiles is more likely (though by no means
certain) to work correctly. (Python springs to mind.) Of course you've
been offered this advice before.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <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"
 
Reply With Quote
 
Angel
Guest
Posts: n/a
 
      09-03-2012
On 2012-09-03, Bill Cunningham <(E-Mail Removed)> wrote:
> I worked and worked on this code until my compiler gave no more errors
> even with -Wall -ansi turned on. So I think it's valid. The question is is
> it doing what I want it to. I don't think so. Its never stopped and I've had
> to interrupt it while running. I get a bunch of textual 00 all across the
> screen. The idea is to take a binary and convert it to text and print it in
> hex. I never get out of the do-while loop. Like a hex dump does but a hex
> dump doesn't convert a binary into text. Is what I'm wanting valid? Am I
> getting what I'm asking for. Here's the code if your reader lets you read it
> neatly.


Here's a very short and simple program that reads a file and dumps the
contents as hexadecimal numbers. Error checking and reading the file
name from the command line instead of hard-coding it in are left as
exercises to the reader.

I think it is error-free and standard-compliant, but if not I'm sure
someone in the group will set me straight. ^^


#include <stdio.h>

#if !defined(BUFSIZ)
#define BUFSIZ ((size_t) 4096u)
#endif

int main(void)
{
FILE *file = fopen("/bin/ls", "rb");
unsigned char buf[BUFSIZ];
size_t nread;

while ((nread = fread(buf, sizeof(unsigned char), BUFSIZ, file)) > 0)
{
for (size_t foo = 0; foo < nread; foo++)
{
printf("%02x ", buf[foo]);
}
}
fclose(file);
}


--
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      09-03-2012
"Bill Cunningham" <(E-Mail Removed)> writes:

> I worked and worked on this code until my compiler gave no more errors
> even with -Wall -ansi turned on. So I think it's valid. The question is is
> it doing what I want it to. I don't think so. Its never stopped and I've had
> to interrupt it while running. I get a bunch of textual 00 all across the
> screen. The idea is to take a binary and convert it to text and print it in
> hex. I never get out of the do-while loop. Like a hex dump does but a hex
> dump doesn't convert a binary into text. Is what I'm wanting valid? Am I
> getting what I'm asking for. Here's the code if your reader lets you read it
> neatly.
>
> Bill
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(void)
> {
> int buf[8200];
> unsigned buf2[8200];
> FILE *fp, *fp2;
> if ((fp = fopen("6", "rb")) == NULL) {
> perror("fopen 1");
> exit(1);
> }
> if ((fp2 = fopen("b", "wt")) == NULL) {
> perror("fopen 2");
> exit(1);
> }
> do {
> *buf = fscanf(fp, "%i", buf);
> fprintf(fp2, "%i %x", *buf, *buf2);
> }
> while (*buf != EOF);
> fclose(fp);
> fclose(fp2);
> printf(" %i %u", *buf, *buf2);
> return 0;
> }


There are four big things wrong here.

(1) The termination condition of the loop is wrong. It is always
better, when using scanf and friends, to loop while the function reports
success. Don't loop while it isn't something you don't want, loop while
it what you do want. In this case, fscanf will report 1 if it reads one
number so loop while the result is one.

(2) The place where you put the number read is the same place where you
store the success/failure result from fscanf. Even if the fscanf
succeeded in putting a number into the location pointed to by buf, that
number would be destroyed by putting a one into *buf (the same place).

(3) fscanf can't do what you want (well it can if you bend the rules but
that's not a good idea). Its purpose is to read textual data (e.g
sequences of digits in some text encoding like ASCII) and produce the
internal (binary) representation that your machine uses. That's exactly
the opposite of what you want to do.

(4) You print a piece of uninitialised data. *buf2 has never had
anything put into it so the output you will get is not based on the
input.

There are some other points: using 8200 element arrays when you use only
one element from each; writing "rt" in your second fopen call; printing
inside the loop even if the input fails; printing again outside the loop
and using a printf format such that you won't be able to interpret the
output, but those are all minor compared to the Big Four.

--
Ben.
 
Reply With Quote
 
Bill Cunningham
Guest
Posts: n/a
 
      09-03-2012
Keith Thompson wrote:
> "Bill Cunningham" <(E-Mail Removed)> writes:
> [...]
>> The idea is to take a binary and convert it to text and
>> print it in hex. I never get out of the do-while loop. Like a hex
>> dump does but a hex dump doesn't convert a binary into text.

>
> A hex dump *does* convert a binary into text. What did you think a
> hex dump does?
>
> [...]
>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main(void)
>> {
>> int buf[8200];
>> unsigned buf2[8200];
>> FILE *fp, *fp2;
>> if ((fp = fopen("6", "rb")) == NULL) {
>> perror("fopen 1");
>> exit(1);
>> }

>
> Your indentation is messed up. I suspect that you're indenting with
> a mix of spaces and tabs, and the tabs are getting lost somewhere
> between your news client and mine. Figure out how to indent with
> spaces only, at least for code you post. (Filtering through the Unix
> "expand" command is one way to do this.)
>
> [...]
>
>> do {
>> *buf = fscanf(fp, "%i", buf);
>> fprintf(fp2, "%i %x", *buf, *buf2);
>> }
>> while (*buf != EOF);

>
> For a do-while loop, it's clearer to put the while on the same line as
> the "}"; otherwise it looks very much like a while loop.
>
> [...]
>
> There are numerous other problems with your code.
>
> As you should realize by now, just getting a C program to compile
> doesn't imply that it's going to work. There are other languages
> where code that just compiles is more likely (though by no means
> certain) to work correctly. (Python springs to mind.) Of course
> you've been offered this advice before.


My indentation seems to always mess up when writing to a newsreader.
When I write code I do use a tab. For about every line then run it through
indent. The result looks perfect. Then I run it through unix2dos to
straighten out the lines and post from OE using my XP. Somewhere in there
the indentation messes up. I was leary about using fscanf and fprintf anyway
here. The thought was the conversion ability to turn binary to text.

B


 
Reply With Quote
 
Bill Cunningham
Guest
Posts: n/a
 
      09-03-2012
Ben Bacarisse wrote:

> There are four big things wrong here.
>
> (1) The termination condition of the loop is wrong. It is always
> better, when using scanf and friends, to loop while the function
> reports success. Don't loop while it isn't something you don't want,
> loop while it what you do want. In this case, fscanf will report 1
> if it reads one number so loop while the result is one.
>
> (2) The place where you put the number read is the same place where
> you store the success/failure result from fscanf. Even if the fscanf
> succeeded in putting a number into the location pointed to by buf,
> that number would be destroyed by putting a one into *buf (the same
> place).
>
> (3) fscanf can't do what you want (well it can if you bend the rules
> but that's not a good idea). Its purpose is to read textual data (e.g
> sequences of digits in some text encoding like ASCII) and produce the
> internal (binary) representation that your machine uses. That's
> exactly the opposite of what you want to do.


I was leary as I said in another post about using fscanf and fprintf for
this. I was playing around with some code trying to learn something and
thought I'd post in order to learn something. Thanks for the advice. In
dealing with binary I'll stay away from fscanf and fprintf from now on. I
really don't know much about the *scanf family anyway.

Bill

> (4) You print a piece of uninitialised data. *buf2 has never had
> anything put into it so the output you will get is not based on the
> input.
>
> There are some other points: using 8200 element arrays when you use
> only one element from each; writing "rt" in your second fopen call;
> printing inside the loop even if the input fails; printing again
> outside the loop and using a printf format such that you won't be
> able to interpret the output, but those are all minor compared to the
> Big Four.



 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      09-03-2012
"Bill Cunningham" <(E-Mail Removed)> writes:

> Ben Bacarisse wrote:

<snip>
>> (3) fscanf can't do what you want (well it can if you bend the rules
>> but that's not a good idea). Its purpose is to read textual data (e.g
>> sequences of digits in some text encoding like ASCII) and produce the
>> internal (binary) representation that your machine uses. That's
>> exactly the opposite of what you want to do.

>
> I was leary as I said in another post about using fscanf and fprintf for
> this. I was playing around with some code trying to learn something and
> thought I'd post in order to learn something. Thanks for the advice. In
> dealing with binary I'll stay away from fscanf and fprintf from now on. I
> really don't know much about the *scanf family anyway.


That's interesting. Why do will you stay away from fprintf when dealing
with binary data?

<snip>
--
Ben.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      09-03-2012
Ben Bacarisse <(E-Mail Removed)> writes:

> "Bill Cunningham" <(E-Mail Removed)> writes:
>
>> Ben Bacarisse wrote:

> <snip>
>>> (3) fscanf can't do what you want (well it can if you bend the rules
>>> but that's not a good idea). Its purpose is to read textual data (e.g
>>> sequences of digits in some text encoding like ASCII) and produce the
>>> internal (binary) representation that your machine uses. That's
>>> exactly the opposite of what you want to do.

>>
>> I was leary as I said in another post about using fscanf and fprintf for
>> this. I was playing around with some code trying to learn something and
>> thought I'd post in order to learn something. Thanks for the advice. In
>> dealing with binary I'll stay away from fscanf and fprintf from now on. I
>> really don't know much about the *scanf family anyway.

>
> That's interesting. Why do will you stay away from fprintf when dealing
> with binary data?


s/do will/will/

--
Ben.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
what is the difference between code inside a <script> tag and code in the code-behind file? keithb ASP .Net 1 03-29-2006 01:00 AM
Fire Code behind code AND Javascript code associated to a Button Click Event =?Utf-8?B?Q2FybG8gTWFyY2hlc29uaQ==?= ASP .Net 4 02-11-2004 07:31 AM
Re: Code Behind vs. no code behind: error Ben Miller [msft] ASP .Net 1 06-28-2003 01:46 AM
Re: C# Equivalent of VB.Net Code -- One line of code, simple Ian ASP .Net 0 06-25-2003 01:14 PM
Re: C# Equivalent of VB.Net Code -- One line of code, simple Ron ASP .Net 1 06-24-2003 07:18 PM



Advertisments