Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #10063 > unrolled thread

hexump.c

Back to article view | Back to comp.lang.c

Contents

  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 1 of 5  [1] 2 3 4 5  Next page →

#10063 — hexump.c

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;
    }
    int oneChar = fgetc(file);
    int column = 0,line = 0;
    unsigned char tab[16+1];
    char *hex = "0123456789abcdef";
    int address = 1;

    while (oneChar != EOF) {
       if (column == 0) {
          memset(tab,'.',16);
          fprintf(stdout,"[%d] ",address);
       }
       if (oneChar >= ' ' && oneChar <= 127) {
          tab[column] = oneChar;
       }
       fputc(hex[(oneChar >> 4)&0xf],stdout);
       fputc(hex[oneChar&0xf],stdout);
       fputc(' ',stdout);
       column++;
       if (column == 16) {
          fputc(' ',stdout);
          tab[column]=0;
          fputs(tab,stdout);
          column = 0;
       }
       line++;
       if (line == 16) {
          fputc('\n',stdout);
          line = 0;
       }
       oneChar = fgetc(file);
       address++;
    }
    fclose(file);
    address--;
    if (column > 0 ) {
       while (column < 16) {
          fprintf(stdout,"   ");
          tab[column]=' ';
          column++;
       }
       tab[16]=0;
       fprintf(stdout," %s\n[%d]\n",tab,address);
    }
    else fprintf(stdout,"[%d]\n",address);
    return EXIT_SUCCESS;
}

----------------------------------------------------cut here

[toc] | [next] | [standalone]

#10065

jacob navia writes:
>        fprintf(stderr,"Usage: %s <file name>\n",argv[0]); return
fails if argv[0] is null

>     unsigned char tab[16+1];

you should use char to store printable characters

>        if (oneChar >= ' ' && oneChar <= 127) {
>           tab[column] = oneChar;
>        }

could lead to unprintable characters appearing on non-ascii systems

>        fputc(hex[(oneChar >> 4)&0xf],stdout);

the mask is unnecessary unless you are targeting systems with CHAR_BIT>8

>           fprintf(stdout,"   ");

you know there is a function called printf?

looks like your C code for trivial exercises is just as sloppy as the 
code in your buggy and overpriced compiler jacob.

[toc] | [prev] | [next] | [standalone]

#10067

Le 09/09/11 23:06, tea strainer a écrit :
> jacob navia writes:
>>         fprintf(stderr,"Usage: %s<file name>\n",argv[0]); return
> fails if argv[0] is null
>
>>      unsigned char tab[16+1];
>
> you should use char to store printable characters

OK
>
>>         if (oneChar>= ' '&&  oneChar<= 127) {
>>            tab[column] = oneChar;
>>         }
>
> could lead to unprintable characters appearing on non-ascii systems
>

Yes, I will replace this with isprint()


>>         fputc(hex[(oneChar>>  4)&0xf],stdout);
>
> the mask is unnecessary unless you are targeting systems with CHAR_BIT>8
>

You are just wrong. If I would follow you I would risk a segment
violation.

>>            fprintf(stdout,"   ");
>
> you know there is a function called printf?
>

I said in the introduction to the code that I did not want to use 
implicit stdout since the output file will be changed as an exercise.

But yes, I did not know about printf, thanks


> looks like your C code for trivial exercises is just as sloppy as the
> code in your buggy and overpriced compiler jacob.

You are too coward to insult people openly, you hide behind a pseudonym.

Good bye "tea strainer".

[toc] | [prev] | [next] | [standalone]

#10167

On Sep 9, 2:06 pm, tea strainer <nos...@nospam.com> wrote:
> jacob navia writes:
> >        fprintf(stderr,"Usage: %s <file name>\n",argv[0]); return
>
> fails if argv[0] is null
>
> >     unsigned char tab[16+1];
>
> you should use char to store printable characters
>
> >        if (oneChar >= ' ' && oneChar <= 127) {
> >           tab[column] = oneChar;
> >        }
>
> could lead to unprintable characters appearing on non-ascii systems
>
> >        fputc(hex[(oneChar >> 4)&0xf],stdout);
>
> the mask is unnecessary unless you are targeting systems with CHAR_BIT>8
>
> >           fprintf(stdout,"   ");
>
> you know there is a function called printf?
>
> looks like your C code for trivial exercises is just as sloppy as the
> code in your buggy and overpriced compiler jacob.

printf is a much more expensive operation to output one char versus
fputc or putchar

[toc] | [prev] | [next] | [standalone]

#10066

On 09/10/11 08:53 AM, jacob navia 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;
>      }
>      int oneChar = fgetc(file);
>      int column = 0,line = 0;
>      unsigned char tab[16+1];

This should be char, not unsigned char.

>      char *hex = "0123456789abcdef";

This should be const char*.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#10068

Le 09/09/11 23:18, Ian Collins a écrit :
> On 09/10/11 08:53 AM, jacob navia wrote:

>> unsigned char tab[16+1];
>
> This should be char, not unsigned char.
>
>> char *hex = "0123456789abcdef";
>
> This should be const char*.
>

Right on both counts. Thanks Ian.

[toc] | [prev] | [next] | [standalone]

#10070

On 2011-09-09, jacob navia <jacob@spamsink.net> wrote:
> #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]);

Undefined behaviour in the (unlikely) case where argc = 0 and argv[0] = NULL.

>        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;
>     }
>     int oneChar = fgetc(file);
>     int column = 0,line = 0;

The variables column and line serve the same purpose.
One of them can go.

>     unsigned char tab[16+1];

Why unsigned?

>     char *hex = "0123456789abcdef";
>     int address = 1;
>
>     while (oneChar != EOF) {
>        if (column == 0) {
>           memset(tab,'.',16);
>           fprintf(stdout,"[%d] ",address);
>        }
>        if (oneChar >= ' ' && oneChar <= 127) {
>           tab[column] = oneChar;
>        }
>        fputc(hex[(oneChar >> 4)&0xf],stdout);
>        fputc(hex[oneChar&0xf],stdout);
>        fputc(' ',stdout);
>        column++;
>        if (column == 16) {
>           fputc(' ',stdout);
>           tab[column]=0;
>           fputs(tab,stdout);
>           column = 0;
>        }
>        line++;
>        if (line == 16) {
>           fputc('\n',stdout);
>           line = 0;
>        }
>        oneChar = fgetc(file);
>        address++;
>     }
>     fclose(file);
>     address--;
>     if (column > 0 ) {
>        while (column < 16) {
>           fprintf(stdout,"   ");
>           tab[column]=' ';
>           column++;
>        }
>        tab[16]=0;
>        fprintf(stdout," %s\n[%d]\n",tab,address);
>     }
>     else fprintf(stdout,"[%d]\n",address);
>     return EXIT_SUCCESS;
> }

The output would look nicer (better aligned) if the address
were printed using a constant field width. Now it looks like this:

[1] 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
[17] 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
[33] 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
[49] 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
[65] 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
[81] 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
[97] 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
[113] 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 0a  xxxxxxxxxxxxxxx.
[128]

Note the misalignment between first/second and seventh/eighth lines.

And personally I find the one-based addresses a bit odd, but
perhaps that's just me.

[toc] | [prev] | [next] | [standalone]

#10072

Le 10/09/11 00:29, Ike Naar a écrit :
> On 2011-09-09, jacob navia<jacob@spamsink.net>  wrote:
>> #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]);
>
> Undefined behaviour in the (unlikely) case where argc = 0 and argv[0] = NULL.
>

Yes. But do you know a system where that happens?

Never found one.

>>         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;
>>      }
>>      int oneChar = fgetc(file);
>>      int column = 0,line = 0;
>
> The variables column and line serve the same purpose.
> One of them can go.
>

No, lines count the lines and columns the number of chars
read in that line of output.

>>      unsigned char tab[16+1];
>
> Why unsigned?
>


Bug. Changed that to plain char.

>
> The output would look nicer (better aligned) if the address
> were printed using a constant field width. Now it looks like this:
>
> [1] 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
> [17] 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
> [33] 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
> [49] 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
> [65] 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
> [81] 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
> [97] 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
> [113] 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 0a  xxxxxxxxxxxxxxx.
> [128]
>
> Note the misalignment between first/second and seventh/eighth lines.

Yes, that will be one exercise. But to solve it, you have to know the
size of the file in order to know how many places you need.

>
> And personally I find the one-based addresses a bit odd, but
> perhaps that's just me.

Many exercises will be to add options:

1) Option for zero based addresses in hex
2) Option for decimal dump instead of hexadecimal
3) Option for writing the output into a file instead of
    stdout.
4) Option to print more/less than 16 characters
5) Option to limit the output to N text positions
6) Option to dump in 16/32 bit format instead of 8.

Thanks for your answer

jacob

[toc] | [prev] | [next] | [standalone]

#10073

On 2011-09-09, jacob navia <jacob@spamsink.net> wrote:
> Le 10/09/11 00:29, Ike Naar a ?crit :
>> On 2011-09-09, jacob navia<jacob@spamsink.net>  wrote:
>>> #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]);
>>
>> Undefined behaviour in the (unlikely) case where argc = 0 and argv[0] = NULL.
>
> Yes. But do you know a system where that happens?
> Never found one.

I agree that argc = 0 is unlikely. But the standard allows it.

>>>      int column = 0,line = 0;
>>
>> The variables column and line serve the same purpose.
>> One of them can go.
>>
>
> No, lines count the lines and columns the number of chars
> read in that line of output.

Are you really really sure?
I get the impression that they both represent the number of columns,
and that line==column is an invariant of the
``while (oneChar != EOF)'' loop.

[toc] | [prev] | [next] | [standalone]

#10074

Le 10/09/11 00:53, Ike Naar a écrit :
>
> Are you really really sure?
> I get the impression that they both represent the number of columns,
> and that line==column is an invariant of the
> ``while (oneChar != EOF)'' loop.

A REAL BUG!

Thanks a lot. Of course, line should be incremented only when
column goes to zero.

Thanks!

jacob

[toc] | [prev] | [next] | [standalone]

#10176

On 2011-09-09, Ike Naar <ike@iceland.freeshell.org> wrote:
> I agree that argc = 0 is unlikely. But the standard allows it.

I think there was some system with the convention that argc = 0 meant
that argv[1] was a pointer to a system-specific magical structure that
had information about a GUI invocation or something to that effect.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#10180

Le 13/09/11 08:44, Seebs a écrit :
> On 2011-09-09, Ike Naar<ike@iceland.freeshell.org>  wrote:
>> I agree that argc = 0 is unlikely. But the standard allows it.
>
> I think there was some system with the convention that argc = 0 meant
> that argv[1] was a pointer to a system-specific magical structure that
> had information about a GUI invocation or something to that effect.
>
> -s

WHO CARES?

Not me. I think you can't possible try to satisfy all the systems that
existed some time in the past to make your application portable to
PDP11 or whatever. Specially not for new students of the C language
that will surely work in a PC (windows or linux) or a MacIntosh when
doing their homework.

[toc] | [prev] | [next] | [standalone]

#10195

> Not me. I think you can't possible try to satisfy all the systems that
> existed some time in the past to make your application portable to
> PDP11 or whatever.

Why not, isn't that what the preprocessor is for?

Oh the PDP 11 doesn't have the preprocessor? ;-)

[toc] | [prev] | [next] | [standalone]

#10203 — Teaching C (was Re: hexump.c)

On 9/13/2011 4:33 AM, jacob navia wrote:
> Le 13/09/11 08:44, Seebs a écrit :
>> On 2011-09-09, Ike Naar<ike@iceland.freeshell.org> wrote:
>>> I agree that argc = 0 is unlikely. But the standard allows it.
>>
>> I think there was some system with the convention that argc = 0 meant
>> that argv[1] was a pointer to a system-specific magical structure that
>> had information about a GUI invocation or something to that effect.
>
> WHO CARES?
>
> Not me. I think you can't possible try to satisfy all the systems that
> existed some time in the past to make your application portable to
> PDP11 or whatever. Specially not for new students of the C language
> that will surely work in a PC (windows or linux) or a MacIntosh when
> doing their homework.

I think all classes on C programming should be taught on the DS-9000, unless 
you are specifically teaching "Brand X's C compiler".  It's a lot easier to 
learn "the right way" first and then learn system-specific extensions, than 
it is to learn system-specific extensions and then "unlearn" them when 
working on other platforms.

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#10204 — Re: Teaching C (was Re: hexump.c)

Le 13/09/11 22:36, Kenneth Brody a écrit :

> I think all classes on C programming should be taught on the DS-9000,
> unless you are specifically teaching "Brand X's C compiler". It's a lot
> easier to learn "the right way" first and then learn system-specific
> extensions, than it is to learn system-specific extensions and then
> "unlearn" them when working on other platforms.
>

1) argv[0] is a system specific extension ???? That would be news to me.

2) Can you tell me of an EXISTING system that sets argv[0] to anything
    else than the name of the program?

[toc] | [prev] | [next] | [standalone]

#10218 — Re: Teaching C (was Re: hexump.c)

On Tue, 13 Sep 2011 22:44:28 +0200, jacob navia wrote:

> 2) Can you tell me of an EXISTING system that sets argv[0] to anything
>     else than the name of the program?

Unless running a script (a file beginning with "#!"), Unix sets argv to
exactly what is passed to execve(). If you execute a program with:

	char *arg0 = NULL;
	execve("foo", &arg0, environ);

the resulting program will have "argc == 0 && argv[0] == NULL".

Setting argv[0] to the name of the program is only a convention, not
something which is enforced by the kernel.

[toc] | [prev] | [next] | [standalone]

#10221 — Re: Teaching C (was Re: hexump.c)

Le 14/09/11 14:31, Nobody a écrit :
> On Tue, 13 Sep 2011 22:44:28 +0200, jacob navia wrote:
>
>> 2) Can you tell me of an EXISTING system that sets argv[0] to anything
>>      else than the name of the program?
>
> Unless running a script (a file beginning with "#!"), Unix sets argv to
> exactly what is passed to execve(). If you execute a program with:
>
> 	char *arg0 = NULL;
> 	execve("foo",&arg0, environ);
>
> the resulting program will have "argc == 0&&  argv[0] == NULL".
>
> Setting argv[0] to the name of the program is only a convention, not
> something which is enforced by the kernel.
>

Yes. So, you can crash probably most Unix programs that way.
So what?

Most zip/unzip programs are only one program. They look at argv[0]
to see if they should be unzipping or zipping.

There is no system that doesn't set argv[0] to the name of the program.
I added a guard (if (argv[0]) in the program as presented in the
exercise.

One thing you should consider is that the beginner must begin with
simple programs, not highly secured programs designed to run a simple
hex dump utility in a 100% secure environment. There is NO point in
making hexdump.c more complex than it is already.

[toc] | [prev] | [next] | [standalone]

#10228 — Re: Teaching C (was Re: hexump.c)

On 9/14/11 9:27 AM, jacob navia wrote:
>
> One thing you should consider is that the beginner must begin with
> simple programs, not highly secured programs designed to run a simple
> hex dump utility in a 100% secure environment. There is NO point in
> making hexdump.c more complex than it is already.
>

I feel that in a beginning programming course, it is important to teach 
the students "safe" techniques, and to test for the needed error 
conditions. Maybe the *first* program with input they aren't made (or 
taught) the needed error checks, but then the next lesson should be 
giving that program input that breaks it and how to protect from it.

Maybe then they can be taught that if they KNOW that they control the 
input, then they can be a bit relaxed in checking.

Note that not all errors need to be tested. For instance, in the 
canonical "Hello World" program, you could add a test for error in the 
output, but what would the program do, if output is broken it isn't 
going to be able to output an error message. If in the presence of the 
error, the program can continue and not get into more trouble, then 
ignoring the error can be reasonable. But if they learn to THINK about 
error conditions early, they might not forget as often when it is really 
needed.

[toc] | [prev] | [next] | [standalone]

#10247 — Re: Teaching C (was Re: hexump.c)

jacob navia <jacob@spamsink.net> writes:
> Le 14/09/11 14:31, Nobody a écrit:
>> On Tue, 13 Sep 2011 22:44:28 +0200, jacob navia wrote:
>>
>>> 2) Can you tell me of an EXISTING system that sets argv[0] to anything
>>>      else than the name of the program?

Yes.  I just ran the following program:

#include <stdio.h>
int main(int argc, char **argv) {
    for (int i = 0; i <= argc; i ++) {
        printf("argv[%d] = ", i);
        if (argv[i] == NULL) {
            printf("NULL\n");
        }
        else {
            printf("\"%s\"\n", argv[i]);
        }
    }
    return 0;
}

and it gave me this output:

argv[0] = NULL

I just ran it again and got this output:

argv[0] = "argv[0] is a lie"
argv[1] = NULL

Why?  Because I invoked it from a 6-line C program that uses execv().

>> Unless running a script (a file beginning with "#!"), Unix sets argv to
>> exactly what is passed to execve(). If you execute a program with:
>>
>> 	char *arg0 = NULL;
>> 	execve("foo",&arg0, environ);
>>
>> the resulting program will have "argc == 0&&  argv[0] == NULL".
>>
>> Setting argv[0] to the name of the program is only a convention, not
>> something which is enforced by the kernel.
>>
>
> Yes. So, you can crash probably most Unix programs that way.
> So what?

No, I don't believe you can.  It will only crash Unix programs that
don't blindly assume that argv[0] != NULL.  If you find Unix programs
that crash when invoked with argv[0] == NULL, you should consider
reporting it as a bug.

> Most zip/unzip programs are only one program. They look at argv[0]
> to see if they should be unzipping or zipping.

Perhaps so.  info-zip, the default version on Ubuntu, has separate
executables for zip and unzip.  But grep is a good example -- and
at least the GNU version of grep has an explicit check; if argv[0]
== NULL; it reports it as a bug and aborts.  (At least there's code
to do that; I'm not certain that it's actually used.)  I suspect
that most Unix/Linux programs that care abaout the value of argv[0]
do something similar.

> There is no system that doesn't set argv[0] to the name of the program.

It depends on how you invoke the program.  And I wouldn't bet a lot
on the assumption that "the name of the program" is a name that can be
used to invoke it.

> I added a guard (if (argv[0]) in the program as presented in the
> exercise.

Good for you.  We pointed out the possibility that argv[0] isn't
necessarily non-null and you changed the program to allow for it.

So why are you still whining about it?

> One thing you should consider is that the beginner must begin with
> simple programs, not highly secured programs designed to run a simple
> hex dump utility in a 100% secure environment. There is NO point in
> making hexdump.c more complex than it is already.

Then why did you change it?  I'm glad you did, but it seems
inconsistent with what you've been saying.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#10250 — Re: Teaching C (was Re: hexump.c)

In article <lnpqj2amz7.fsf@nuthaus.mib.org>,
Keith Thompson  <kst-u@mib.org> wrote:
>jacob navia <jacob@spamsink.net> writes:
>>
>> Yes. So, you can crash probably most Unix programs that way.
>> So what?
>
>No, I don't believe you can.  It will only crash Unix programs that
>don't blindly assume that argv[0] != NULL.  If you find Unix programs
>that crash when invoked with argv[0] == NULL, you should consider
>reporting it as a bug.

I've just done this test on several programs. There were many segfaults.
Several print an angry message about argv[0] being NULL and then abort!
It seems to be a "you know exactly what you did and you should be
ashamed of yourself" type of error.

Most disturbing are the many setuid programs that segfaulted, including
passwd, mount, and su.

shells: pdksh, bash, and dash were OK. Others segfaulted.

Jacob seems to have the better assessment of reality here. Many good
programmers don't adequately defend against the argv[0]=0 exec, even in
privileged programs where defensiveness is especially important.

Of course if educational materials omit mention of the argv[0]=0
possibility on the grounds that real programmers don't bother
checking, it becomes a self-perpetuating problem. By the time you
graduate from reading tutorials to reading formal specifications, you've
already developed some habits, and it'd be better if they were good
ones.

-- 
Alan Curry

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web