Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #10063 > unrolled thread
| Started by | jacob navia <jacob@spamsink.net> |
|---|---|
| First post | 2011-09-09 22:53 +0200 |
| Last post | 2011-09-11 13:56 +0200 |
| Articles | 10 on this page of 90 — 31 participants |
Back to article view | Back to comp.lang.c
hexump.c jacob navia <jacob@spamsink.net> - 2011-09-09 22:53 +0200
Re: hexump.c tea strainer <nospam@nospam.com> - 2011-09-09 21:06 +0000
Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-09 23:57 +0200
Re: hexump.c NicStevens <nic.stevens@gmail.com> - 2011-09-12 13:22 -0700
Re: hexump.c Ian Collins <ian-news@hotmail.com> - 2011-09-10 09:18 +1200
Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-09 23:59 +0200
Re: hexump.c Ike Naar <ike@iceland.freeshell.org> - 2011-09-09 22:29 +0000
Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-10 00:39 +0200
Re: hexump.c Ike Naar <ike@iceland.freeshell.org> - 2011-09-09 22:53 +0000
Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-10 00:58 +0200
Re: hexump.c Seebs <usenet-nospam@seebs.net> - 2011-09-13 06:44 +0000
Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-13 10:33 +0200
Re: hexump.c Fritz Wuehler <fritz@spamexpire-201109.rodent.frell.theremailer.net> - 2011-09-13 18:02 +0200
Teaching C (was Re: hexump.c) Kenneth Brody <kenbrody@spamcop.net> - 2011-09-13 16:36 -0400
Re: Teaching C (was Re: hexump.c) jacob navia <jacob@spamsink.net> - 2011-09-13 22:44 +0200
Re: Teaching C (was Re: hexump.c) Nobody <nobody@nowhere.com> - 2011-09-14 13:31 +0100
Re: Teaching C (was Re: hexump.c) jacob navia <jacob@spamsink.net> - 2011-09-14 15:27 +0200
Re: Teaching C (was Re: hexump.c) Richard Damon <news.x.richarddamon@xoxy.net> - 2011-09-14 11:49 -0400
Re: Teaching C (was Re: hexump.c) Keith Thompson <kst-u@mib.org> - 2011-09-14 13:27 -0700
Re: Teaching C (was Re: hexump.c) pacman@kosh.dhis.org (Alan Curry) - 2011-09-14 20:59 +0000
Re: Teaching C (was Re: hexump.c) Nobody <nobody@nowhere.com> - 2011-09-14 22:20 +0100
Re: Teaching C (was Re: hexump.c) James Kuyper <jameskuyper@verizon.net> - 2011-09-14 17:20 -0400
Re: Teaching C (was Re: hexump.c) pacman@kosh.dhis.org (Alan Curry) - 2011-09-15 01:51 +0000
Re: Teaching C (was Re: hexump.c) Keith Thompson <kst-u@mib.org> - 2011-09-14 19:29 -0700
Re: Teaching C (was Re: hexump.c) Keith Thompson <kst-u@mib.org> - 2011-09-14 19:21 -0700
Re: Teaching C Ben Pfaff <blp@cs.stanford.edu> - 2011-09-14 19:58 -0700
Re: Teaching C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-09-14 21:55 -0600
Re: Teaching C James Kuyper <jameskuyper@verizon.net> - 2011-09-15 06:54 -0400
Re: Teaching C Keith Thompson <kst-u@mib.org> - 2011-09-15 11:58 -0700
Re: Teaching C Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 12:57 -0800
Re: Teaching C Nobody <nobody@nowhere.com> - 2011-09-15 14:25 +0100
Re: Teaching C Seebs <usenet-nospam@seebs.net> - 2011-09-16 22:00 +0000
Re: Teaching C (was Re: hexump.c) Kenneth Brody <kenbrody@spamcop.net> - 2011-09-14 12:54 -0400
Re: Teaching C (was Re: hexump.c) James Kuyper <jameskuyper@verizon.net> - 2011-09-14 13:26 -0400
Re: Teaching C (was Re: hexump.c) jacob navia <jacob@spamsink.net> - 2011-09-14 19:33 +0200
Re: Teaching C (was Re: hexump.c) jameskuyper <jameskuyper@verizon.net> - 2011-09-14 11:33 -0700
Re: Teaching C (was Re: hexump.c) jacob navia <jacob@spamsink.net> - 2011-09-14 21:17 +0200
Re: Teaching C (was Re: hexump.c) Kenneth Brody <kenbrody@spamcop.net> - 2011-09-16 11:47 -0400
Re: Teaching C (was Re: hexump.c) Seebs <usenet-nospam@seebs.net> - 2011-09-14 20:43 +0000
Re: Teaching C (was Re: hexump.c) Nobody <nobody@nowhere.com> - 2011-09-14 22:35 +0100
Re: Teaching C (was Re: hexump.c) gordonb.8a7i1@burditt.org (Gordon Burditt) - 2011-09-14 17:31 -0500
Re: Teaching C (was Re: hexump.c) jacob navia <jacob@spamsink.net> - 2011-09-14 19:32 +0200
Re: Teaching C (was Re: hexump.c) Kenneth Brody <kenbrody@spamcop.net> - 2011-09-16 11:27 -0400
Re: Teaching C (was Re: hexump.c) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-16 08:49 -0700
Re: Teaching C (was Re: hexump.c) James Kuyper <jameskuyper@verizon.net> - 2011-09-17 15:04 -0400
Re: hexump.c Keith Thompson <kst-u@mib.org> - 2011-09-13 20:31 -0700
Re: hexump.c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-14 03:22 -0700
Re: hexump.c "BartC" <bc@freeuk.com> - 2011-09-14 11:40 +0100
Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-14 13:54 +0200
Re: hexump.c Nobody <nobody@nowhere.com> - 2011-09-14 13:50 +0100
Re: hexump.c Keith Thompson <kst-u@mib.org> - 2011-09-14 11:35 -0700
Re: hexump.c Seebs <usenet-nospam@seebs.net> - 2011-09-14 19:12 +0000
Re: hexump.c John Bode <jfbode1029@gmail.com> - 2011-09-14 15:31 -0700
Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-15 00:59 +0200
Re: hexump.c Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-14 23:14 +0000
Re: hexump.c John Bode <jfbode1029@gmail.com> - 2011-09-15 08:52 -0700
Re: hexump.c Jens Gustedt <jens.gustedt@loria.fr> - 2011-09-14 21:22 +0200
Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-14 21:26 +0200
Re: hexump.c Ian Collins <ian-news@hotmail.com> - 2011-09-15 07:32 +1200
Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-14 21:44 +0200
Re: hexump.c Keith Thompson <kst-u@mib.org> - 2011-09-14 13:49 -0700
Re: hexump.c Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-16 00:50 +0300
Re: hexump.c Keith Thompson <kst-u@mib.org> - 2011-09-15 18:34 -0700
Re: hexump.c Keith Thompson <kst-u@mib.org> - 2011-09-14 12:16 -0700
Hypocrites jacob navia <jacob@spamsink.net> - 2011-09-14 21:40 +0200
Re: Hypocrites Keith Thompson <kst-u@mib.org> - 2011-09-14 19:11 -0700
Re: hexump.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-14 15:05 +0100
Re: hexump.c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-14 07:56 -0700
Re: hexump.c "BartC" <bc@freeuk.com> - 2011-09-14 17:23 +0100
Re: hexump.c Seebs <usenet-nospam@seebs.net> - 2011-09-14 19:12 +0000
Re: hexump.c John Bode <jfbode1029@gmail.com> - 2011-09-14 15:24 -0700
Re: hexump.c gordonb.ik17p@burditt.org (Gordon Burditt) - 2011-09-09 18:16 -0500
Re: hexump.c Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-12 22:24 +0000
Re: hexump.c "Morris Keesan" <mkeesan@post.harvard.edu> - 2011-09-09 20:33 -0400
Re: hexump.c Ian Collins <ian-news@hotmail.com> - 2011-09-10 12:42 +1200
Re: hexump.c "Morris Keesan" <mkeesan@post.harvard.edu> - 2011-09-10 17:16 -0400
Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-10 10:03 +0200
Re: hexump.c Nobody <nobody@nowhere.com> - 2011-09-10 10:04 +0100
Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-10 11:41 +0200
Re: hexump.c pete <pfiland@mindspring.com> - 2011-09-10 05:51 -0400
Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-10 12:38 +0200
Re: hexump.c Nobody <nobody@nowhere.com> - 2011-09-10 17:53 +0100
Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-10 12:46 +0200
Re: hexump.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-10 13:03 +0100
Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-10 15:34 +0200
Re: hexump.c "Morris Keesan" <mkeesan@post.harvard.edu> - 2011-09-10 17:37 -0400
Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-11 00:10 +0200
Re: hexump.c Patrick Scheible <kkt@zipcon.net> - 2011-09-10 21:03 -0700
Re: hexump.c Barry Schwarz <schwarz45@yahoo.com> - 2011-09-11 00:37 -0700
Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-11 13:56 +0200
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-09-10 12:38 +0200 |
| Message-ID | <j4fems$rmo$1@speranza.aioe.org> |
| In reply to | #10089 |
Le 10/09/11 11:51, pete a écrit : > jacob navia wrote: >> >> Le 10/09/11 11:04, Nobody a écrit : > >>>> char *hex = "0123456789abcdef"; >>> >>> This should be "const". And there's no need for a pointer. IOW: >>> >>> const char hex[] = "0123456789abcdef"; >>> >> >> Well, a pointer doesn't harm either. That array wouldn't be >> zero terminated, that's why I do not use that construct. > > The array *would be* zero terminated. > > ISO/IEC 9899:1999 (E) > 6.7.8 Initialization > > 14 An array of character type may be initialized > by a character string literal, > optionally enclosed in braces. > Successive characters of the character string literal > (including the terminating null character if there is room > or if the array is of unknown size) > initialize the elements of the array. > Note that it says: "If there is room"... It could be not zero terminated and it was like that that I remembered that construct. A newcomer could write: char str[4] = "abcd"; He would receive no warnings, not a hint of what is wrong.
[toc] | [prev] | [next] | [standalone]
| From | Nobody <nobody@nowhere.com> |
|---|---|
| Date | 2011-09-10 17:53 +0100 |
| Message-ID | <pan.2011.09.10.16.53.52.986000@nowhere.com> |
| In reply to | #10090 |
On Sat, 10 Sep 2011 12:38:20 +0200, jacob navia wrote: > Note that it says: "If there is room"... It could be not zero terminated Not as written. To avoid NUL-termination, you would have to write: const char hex[16] = "0123456789abcdef"; Also, it doesn't matter whether or not it's zero terminated, as you really are using it as an array of characters, rather than as a string.
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-09-10 12:46 +0200 |
| Message-ID | <j4ff5i$st9$1@speranza.aioe.org> |
| In reply to | #10063 |
Here is the hexdump with code, commentaries and
exercises. I have incorporated most remarks and
again thanks for your help:
1 #include <stdio.h>
2 #include <stdlib.h>
3 #include <string.h>
4 #include <ctype.h>
5 int main(int argc,char *argv[])
6 {
7 if (argc < 2) {
8 fprintf(stderr,"Usage: %s <file name>\n",argv[0]);
9 return EXIT_FAILURE;
10 }
11 FILE *file = fopen(argv[1],"rb");
12 if (file == NULL) {
13 fprintf(stderr,"Impossible to open %s for reading\n",argv[1]);
14 return EXIT_FAILURE;
15 }
16 int oneChar = fgetc(file);
17 int column = 0,line = 0;
18 char tab[16+1];
19 const char *hex = "0123456789abcdef";
20 int address = 1;
21
22 while (oneChar != EOF) {
23 if (column == 0) {
24 memset(tab,'.',16);
25 fprintf(stdout,"[%d] ",address);
26 }
27 if (isprint(oneChar)) {
28 tab[column] = oneChar;
29 }
30 fputc(hex[(oneChar >> 4)&4],stdout);
31 fputc(hex[oneChar&4],stdout);
32 fputc(' ',stdout);
33 column++;
34 if (column == 16) {
35 fputc(' ',stdout);
36 tab[column]=0;
37 fputs(tab,stdout);
38 column = 0;
39 line++;
40 if (line == 16) {
41 fputc('\n',stdout);
42 line=0;
43 }
44 fputc('\n',stdout);
45 }
46 oneChar = fgetc(file);
47 address++;
48 }
49 fclose(file);
50 address--;
51 if (column > 0 ) {
52 while (column < 16) {
53 fprintf(stdout," ");
54 tab[column]=' ';
55 column++;
56 }
57 tab[16]=0;
58 fprintf(stdout," %s\n[%d]\n",tab,address);
59 }
60 else fprintf(stdout,"[%d]\n",address);
61 return EXIT_SUCCESS;
62 }
Analysis:
--------
The program should be called (in its present form) like this:
hexdump <file name>
i.e. it needs at least one argument: the name of the file to dump.
We test for this in line 7 and if the name is missing we issue a
warning and exit with a failure value. When printing the warning
we use the value stored in argv[0] as the name of the program.
This is generally the case, most systems will store the name of the
program in argv[0]. It could be however, that a malicious user
calls this program constructing its command line for an "execv" call
and leaves argv[0] empty. In that case our program would crash.
Is that possibility a real one? Should we guard against it?
It is highly unlikely that a user that has already enough
access to the machine to write (and compile) programs would
bother to crash our minuscule hexdump utility.. But anyway
the guard would need a tiny change only. Line 8 would need
to be changed to:
8 if (argv[0]) fprintf(stderr,"...message",argv[0]);
Now we know that we have at least an argument. In line 11 we
try to open the file that we should dump. Note that we use the
binary form of the fopen call "rb" (read binary) to dump
exactly each byte in the file.
If we can't open the file (fopen returns NULL) we print a
warning message into the error output file and return a
failure value.
Now we know we have an open file to dump (line 16) so we
start initializing stuff for the main part of the program.
We read the first character into a variable that will hold
each character in the loop (line 16). We will count columns
and lines, so we initialize the counters to zero (line 17).
We need a table of characters to hold the ASCII equivalences
of each byte (line 18). That table should be a string, so
we dimension it to one character more than the required
length.
We need a table of hexadecimal letters (line 19) that shouldn't
be changed, it is a constant "variable". We tell the compiler
this fact. And then we need to know at what position we are
in the file, so we declare an "address" counter. It is initialized
to one since we have already read one character in line 16.
Now we arrive at our loop. We will read and display characters
until the last character of the file, i.e. until we hit the
end of file condition (line 22).
If we are at the start of a line, i.e. when our "column" variable
is at the start of a line we set the table of ASCII equivalences
to '.' and we put out the position of the file where we are.
We use a one based index for our position so that the first character
is 1. But maybe that is not what the user of an hexdump utility
expects, we can change that to a different address field display,
see the exercises at the end.
We should put the contents of our character into the table if
it is printable. We use the 'isprint' function (line 27) to
determine that, and if true we store the value of our character
into the table.
Then, we output the value of our character. We print in hexadecimal
first the higher 4 bits, then the lower 4 bits. Since 4 bit
numbers can only go from zero to 15, we index directly our "hex" table
with the value of those 4 bits lines 30 and 31.
Note that we mask the bits with the value 0xf, i.e. 15. This means
that we ensure that only the lower 4 bits are used. This is important
to avoid making an index error when we access our "hex" table.
We assume that characters are 8 bits. See exercise 6.
We separate each character with a space (line 32) update our column
counter and test if we have arrived at the end of our dump line.
If that is the case we put an extra blank, finish the table with zero
and print it. We bump our "line" counter, and if we have arrived
at a block of 16 lines, we put an extra empty line (line 41).
We separate lines (line 44) and read the next character (line 46).
When we arrive at the end of file the loop stops, and execution
continues with line 49, where we close the file we have opened.
This is not strictly necessary in this case since when a program
exits all the files it has opened are close automatically in most
systems, but it is better to do it since if we later want to use
our dump routine as a part of a bigger software package we would
leave a file open.
We adjust the address since we have counted the EOF as a character
in line 50.
We are at the end of the file we output the last line, if any. If
the file size is not a multiple of 16, we have already put some
characters: we complete the last line with blanks. If the file
size is exactly a multiple of 16 we just output our address variable
to indicate to the user the exact size of the file.
Exercises:
---------
1: Add an optional argument so that an output file can be specified.
2: You should have noticed that between the 9th and the 10th line
the output is not aligned since 10 has one more character than
9. Fix this. All lines should be aligned.
3: Add an option (call it -hexaddress) to write file addresses in
hexadecimal instead of decimal as shown.
4: Add another option (call it -column:XXX) todisplay more or less
text positions in a line. For instance -column:80 would fix the
display to 80 columns. Adjust the number of characters displayed
accordingly. Note that you should not make the number of characters
less than 4 or greater than 512.
5: Add an option to display 32 bits instead of just 8 at a time.
6: What would happen if you are working in a machine where the
characters are 16 bits wide? What needs to be changed in the
above program?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-09-10 13:03 +0100 |
| Message-ID | <0.c6fdf4cf73ac28d89e3d.20110910130316BST.87zkic1u63.fsf@bsb.me.uk> |
| In reply to | #10091 |
jacob navia <jacob@spamsink.net> writes: > Here is the hexdump with code, commentaries and > exercises. I have incorporated most remarks and > again thanks for your help: I would prefer more horizontal white space. Although this is a matter of style, I think it has a significant impact on readability. I accept that you may disagree, but at least you should aim to be consistent in a tutorial exercise. For example, some assignments have space round the '=' and some do not. Some operators get spaces round them and others do not. E.g.: > 30 fputc(hex[(oneChar >> 4)&4],stdout); You've introduced a bug here at some point. Also here: > 31 fputc(hex[oneChar&4],stdout); Two of the three 4s should be 15 (as they used to be). <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-09-10 15:34 +0200 |
| Message-ID | <j4fp1r$l7a$1@speranza.aioe.org> |
| In reply to | #10093 |
Le 10/09/11 14:03, Ben Bacarisse a écrit : > jacob navia<jacob@spamsink.net> writes: > >> Here is the hexdump with code, commentaries and >> exercises. I have incorporated most remarks and >> again thanks for your help: > > I would prefer more horizontal white space. Although this is a matter > of style, I think it has a significant impact on readability. I accept > that you may disagree, but at least you should aim to be consistent in a > tutorial exercise. For example, some assignments have space round the > '=' and some do not. Some operators get spaces round them and others do > not. E.g.: > >> 30 fputc(hex[(oneChar>> 4)&4],stdout); > > You've introduced a bug here at some point. Also here: > >> 31 fputc(hex[oneChar&4],stdout); > > Two of the three 4s should be 15 (as they used to be). > > <snip> Yes, and I corrected it in the code and not in the text as you can see. Anyway the explanation is (I hope) OK :-) Thanks Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morris Keesan" <mkeesan@post.harvard.edu> |
|---|---|
| Date | 2011-09-10 17:37 -0400 |
| Message-ID | <op.v1l3n5um5qv6o3@toshiba-laptop> |
| In reply to | #10091 |
On Sat, 10 Sep 2011 06:46:09 -0400, jacob navia <jacob@spamsink.net> wrote:
> 18 char tab[16+1];
...
> 24 memset(tab,'.',16);
...
> 34 if (column == 16) {
...
> 40 if (line == 16) {
...
> 52 while (column < 16) {
...
> 57 tab[16]=0;
I usually deduct points from students who use uncommented bare magic
numbers like this. Especially when the program is related to
base-16 (hexadecimal) output, and where the 16 in line 40 seems to be
unrelated to any of the other 16s. This might be a good time to
introduce the sizeof operator, and/or #defines. If they've already
been introduced, consider adding, as an exercise, "What would you need
to change to print a different number of characters per line?"
> 6: What would happen if you are working in a machine where the
> characters are 16 bits wide? What needs to be changed in the
> above program?
What about if you are working with a machine where the character width
is not a multiple of 4 bits?
(For many years, I worked with a Unix platform where the chars were
ten bits wide. Someone doing hardware design thought this was a good
idea.)
--
Morris Keesan -- mkeesan@post.harvard.edu
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-09-11 00:10 +0200 |
| Message-ID | <j4gn98$878$1@speranza.aioe.org> |
| In reply to | #10110 |
Le 10/09/11 23:37, Morris Keesan a écrit :
> On Sat, 10 Sep 2011 06:46:09 -0400, jacob navia <jacob@spamsink.net> wrote:
>
>
>> 18 char tab[16+1];
> ...
>> 24 memset(tab,'.',16);
> ...
>> 34 if (column == 16) {
> ...
>> 40 if (line == 16) {
> ...
>> 52 while (column < 16) {
> ...
>> 57 tab[16]=0;
>
> I usually deduct points from students who use uncommented bare magic
> numbers like this. Especially when the program is related to
> base-16 (hexadecimal) output, and where the 16 in line 40 seems to be
> unrelated to any of the other 16s. This might be a good time to
> introduce the sizeof operator, and/or #defines.
That's what the exercise 4 should learn to do:
4: Add another option (call it -column:XXX) todisplay more or less
text positions in a line. For instance -column:80 would fix the
display to 80 columns. Adjust the number of characters displayed
accordingly. Note that you should not make the number of characters
less than 4 or greater than 512.
The goal here is to show exactly why those magic numbers aren't OK. I
said that in my original post when I started this thread:
<quote>
Note that the manifest
constants will be replaced by #defines in the exercises, when they
are asked to increase the number of columns, etc.
<end quote>
>
>> 6: What would happen if you are working in a machine where the
>> characters are 16 bits wide? What needs to be changed in the
>> above program?
>
> What about if you are working with a machine where the character width
> is not a multiple of 4 bits?
Ahh the famous Deathstation 9000 you mean?
Let's be realistic, maybe those systems existed in the past but now...
> (For many years, I worked with a Unix platform where the chars were
> ten bits wide. Someone doing hardware design thought this was a good
> idea.)
>
Well, I think you would need another exercise for that :-)
[toc] | [prev] | [next] | [standalone]
| From | Patrick Scheible <kkt@zipcon.net> |
|---|---|
| Date | 2011-09-10 21:03 -0700 |
| Message-ID | <86litvwwry.fsf@zipcon.net> |
| In reply to | #10112 |
jacob navia <jacob@spamsink.net> writes: >> What about if you are working with a machine where the character width >> is not a multiple of 4 bits? > > Ahh the famous Deathstation 9000 you mean? > > Let's be realistic, maybe those systems existed in the past but now... There are still systems with 36-bit words. In order to make a C compiler for those systems, 9-bit chars are used. While such a compiler can meet standard C, way too much C code can't be ported because of the widespread assumption that all the world has 8-bit chars. -- Patrick
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarz45@yahoo.com> |
|---|---|
| Date | 2011-09-11 00:37 -0700 |
| Message-ID | <a8b2c7c2-6d76-41f3-a8ba-e2845f39ef3f@r8g2000prd.googlegroups.com> |
| In reply to | #10063 |
On Sep 9, 1:53 pm, jacob navia <ja...@spamsink.net> wrote:
> Got the idea of adding one more exercise to the tutorial.
>
> The goal is to show a small hexdump utility without any bells and
> whistles, and add a bunch of exercises to add those. Here it is.
>
> It uses standard C. Please tell me if there could be any
> portability problems.
>
> I do not use putchar but fputc to make it easier to add an output
> file later as one more argument.
>
> Please tell me if you see any errors in it. Note that the manifest
> constants will be replaced by #defines in the exercises, when they
> are asked to increase the number of columns, etc.
>
> ------------------------------------------------------cut here
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> int main(int argc,char *argv[])
> {
> if (argc < 2) {
> fprintf(stderr,"Usage: %s <file name>\n",argv[0]);
> return EXIT_FAILURE;
> }
> FILE *file = fopen(argv[1],"rb");
> if (file == NULL) {
> fprintf(stderr,"Impossible to open %s for reading\n",argv[1]);
> return EXIT_FAILURE;
> }
<snip>
Unless the student is required to have a C99 compiler, all your
declarations should precede your statements.
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-09-11 13:56 +0200 |
| Message-ID | <j4i7l9$c0q$1@speranza.aioe.org> |
| In reply to | #10125 |
Le 11/09/11 09:37, Barry Schwarz a écrit : > > Unless the student is required to have a C99 compiler, all your > declarations should precede your statements. Well, C99 is already 12 years old , so let's require standard C. A C99 compiler exists formost of the wok stations today. PC: lcc-win, gcc, intel Linux: gcc, intel PowerPC: IBM Mac OSX: Apple's gcc (compiles C99 by default) This is a tutorial that starts with standard C, so better get a conforming compiler
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.c
csiph-web