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

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

looking at binary files with C

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

Contents

  looking at binary files with C Uno <Uno@example.invalid> - 2011-06-12 00:06 -0600
    Re: looking at binary files with C Ian Collins <ian-news@hotmail.com> - 2011-06-12 18:41 +1200
      Re: looking at binary files with C Uno <Uno@example.invalid> - 2011-06-12 00:58 -0600
    Re: looking at binary files with C Barry Schwarz <schwarz45@yahoo.com> - 2011-06-12 00:05 -0700
      Re: looking at binary files with C Uno <Uno@example.invalid> - 2011-06-12 01:41 -0600
        Re: looking at binary files with C "Joachim Schmitz" <jojo.nospam@schmitz-digital.de> - 2011-06-12 11:44 +0200
        Re: looking at binary files with C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-12 10:25 -0600
    Re: looking at binary files with C Ike Naar <ike@sverige.freeshell.org> - 2011-06-12 10:26 +0000
    Re: looking at binary files with C Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-12 08:23 -0400
      Re: looking at binary files with C Hans Vlems <hvlems@freenet.de> - 2011-06-13 23:48 -0700
      Re: looking at binary files with C Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-23 00:55 -0700
    Re: looking at binary files with C "BartC" <bc@freeuk.com> - 2011-06-12 14:26 +0100
    Re: looking at binary files with C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-12 10:24 -0600
      Re: looking at binary files with C Uno <Uno@example.invalid> - 2011-06-12 14:47 -0600
        Re: looking at binary files with C "BartC" <bc@freeuk.com> - 2011-06-12 22:23 +0100
          Re: looking at binary files with C Keith Thompson <kst-u@mib.org> - 2011-06-12 14:29 -0700
            Re: looking at binary files with C Uno <Uno@example.invalid> - 2011-06-12 16:31 -0600
              Re: looking at binary files with C Keith Thompson <kst-u@mib.org> - 2011-06-12 16:14 -0700
                Re: looking at binary files with C Uno <Uno@example.invalid> - 2011-06-12 18:41 -0600
        Re: looking at binary files with C Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-12 17:42 -0400
          Re: looking at binary files with C Uno <Uno@example.invalid> - 2011-06-12 17:01 -0600
            Re: looking at binary files with C Keith Thompson <kst-u@mib.org> - 2011-06-12 16:23 -0700
              Re: looking at binary files with C Uno <Uno@example.invalid> - 2011-06-12 17:24 -0600
                Re: looking at binary files with C Ian Collins <ian-news@hotmail.com> - 2011-06-13 11:28 +1200
                  Re: looking at binary files with C Geoff <geoff@invalid.invalid> - 2011-06-12 16:52 -0700
                Re: looking at binary files with C Keith Thompson <kst-u@mib.org> - 2011-06-13 08:51 -0700
              Re: looking at binary files with C Seebs <usenet-nospam@seebs.net> - 2011-06-13 14:39 +0000
                Re: looking at binary files with C Uno <Uno@example.invalid> - 2011-06-13 20:01 -0600
                  Re: looking at binary files with C Keith Thompson <kst-u@mib.org> - 2011-06-13 19:24 -0700
                    Re: looking at binary files with C Seebs <usenet-nospam@seebs.net> - 2011-06-14 17:02 +0000
                      Re: looking at binary files with C Uno <Uno@example.invalid> - 2011-06-16 01:32 -0600
            Re: looking at binary files with C Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-13 07:57 -0400
              Re: looking at binary files with C Uno <Uno@example.invalid> - 2011-06-13 20:23 -0600
                Re: looking at binary files with C Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-13 23:12 -0400
                  Re: looking at binary files with C lovecreatesbeauty <lovecreatesbeauty@gmail.com> - 2011-06-14 01:09 -0700
            Re: looking at binary files with C Oliver Jackson <chexmofo@hotmail.com> - 2011-06-15 20:15 -0700
        Re: looking at binary files with C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-12 18:41 -0600
        Re: looking at binary files with C James Waldby <not@valid.invalid> - 2011-06-13 01:16 +0000
          Re: looking at binary files with C Uno <Uno@example.invalid> - 2011-06-12 19:48 -0600
          Re: looking at binary files with C "io_x" <a@b.c.invalid> - 2011-06-14 12:19 +0200
            Re: looking at binary files with C lovecreatesbeauty <lovecreatesbeauty@gmail.com> - 2011-06-14 03:58 -0700
              Re: looking at binary files with C "io_x" <a@b.c.invalid> - 2011-06-14 19:07 +0200
                Re: looking at binary files with C "io_x" <a@b.c.invalid> - 2011-06-14 19:46 +0200
                Re: looking at binary files with C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-14 16:08 -0600
            Re: looking at binary files with C Ian Collins <ian-news@hotmail.com> - 2011-06-15 08:47 +1200
        Re: looking at binary files with C Hans Vlems <hvlems@freenet.de> - 2011-06-13 23:51 -0700
    Re: looking at binary files with C Michael Press <rubrum@pacbell.net> - 2011-06-15 13:06 -0700
      Re: looking at binary files with C Uno <Uno@example.invalid> - 2011-06-16 01:38 -0600
        Re: looking at binary files with C Michael Press <rubrum@pacbell.net> - 2011-06-16 00:54 -0700
          Re: looking at binary files with C James Waldby <not@valid.invalid> - 2011-06-16 16:59 +0000
        Re: looking at binary files with C "J. J. Farrell" <jjf@bcs.org.uk> - 2011-06-16 18:32 +0100

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

#5881 — looking at binary files with C

$ indent -kr hist1.c
$ cc -Wall -Wextra hist1.c -o hist
$ ./hist
Segmentation fault
$ cat hist1.c
#include <stdio.h>
#define SIZE 100000

int main(void)
{
     int c;
     long counter = 0;
     long a[SIZE];
     long i, j;
     FILE *fp;

     fp = fopen("shoulder.wmv", "rb+");

     for (i = 0; i < SIZE; ++i) {
	a[i] = 0;
     }

     for (j = 0; j < 7000000; ++j) {
	c = fgetc(fp);


	if (c != EOF) {

	    a[counter] = c;
	    counter++;
	} else {
	    for (i = 0; i < 100; ++i) {
		printf("i and frequency is %ld   %ld\n", i, a[i]);
	    }


	    break;
	}
     }
     printf("Counter reached %ld\n", counter);
     fclose(fp);
     return 0;
}

// cc -Wall -Wextra hist1.c -o hist
$

So, why the seg fault?
-- 
Uno

[toc] | [next] | [standalone]

#5884

On 06/12/11 06:06 PM, Uno wrote:
> $ indent -kr hist1.c
> $ cc -Wall -Wextra hist1.c -o hist
> $ ./hist
> Segmentation fault
> $ cat hist1.c
> #include<stdio.h>
> #define SIZE 100000
>
> int main(void)
> {
>       int c;
>       long counter = 0;
>       long a[SIZE];
>       long i, j;
>       FILE *fp;
>
>       fp = fopen("shoulder.wmv", "rb+");

Checking for success here would be a good idea.

-- 
Ian Collins

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

#5886

On 06/12/2011 12:41 AM, Ian Collins wrote:
> On 06/12/11 06:06 PM, Uno wrote:
>> $ indent -kr hist1.c
>> $ cc -Wall -Wextra hist1.c -o hist
>> $ ./hist
>> Segmentation fault
>> $ cat hist1.c
>> #include<stdio.h>
>> #define SIZE 100000
>>
>> int main(void)
>> {
>> int c;
>> long counter = 0;
>> long a[SIZE];
>> long i, j;
>> FILE *fp;
>>
>> fp = fopen("shoulder.wmv", "rb+");
>
> Checking for success here would be a good idea.
>

Data's coming in:

c is 27
c is 25
c is 157
c is 241
c is 16
c is 149
c is 242
c is 192
c is 75
c is 49
c is 40
c is 108
c is 28
c is 76
c is 171
c is 60
c is 174
c is 233
c is 68
c is 50
c is 93
c is 152
c is 240
c is 2
c is 11
c is 172
c is 69
c is 76
c is 189
c is 129
c is 132^C
$ cat hist2.c
#include <stdio.h>
#define SIZE 100000

int main(void)
{
     int c;
     long counter = 0;
     long a[SIZE];
     long i, j;
     FILE *fp;

     fp = fopen("shoulder.wmv", "rb+");

     for (i = 0; i < SIZE; ++i) {
	a[i] = 0;
     }

     for (j = 0; j < 7000000; ++j) {
	c = fgetc(fp);

         printf("c is %d\n", c);


	if (c != EOF) {

	    a[counter] = c;
	    counter++;
	} else {
	    for (i = 0; i < 100; ++i) {
		printf("i and frequency is %ld   %ld\n", i, a[i]);
	    }


	    break;
	}
     }
     printf("Counter reached %ld\n", counter);
     fclose(fp);
     return 0;
}

// cc -Wall -Wextra hist2.c -o hist
$
-- 
Uno

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

#5887

On Jun 11, 11:06 pm, Uno <U...@example.invalid> wrote:
> $ indent -kr hist1.c
> $ cc -Wall -Wextra hist1.c -o hist
> $ ./hist
> Segmentation fault
> $ cat hist1.c
> #include <stdio.h>
> #define SIZE 100000
>
> int main(void)
> {
>      int c;
>      long counter = 0;
>      long a[SIZE];

If long is 4 bytes, this reserves 400,000 bytes.  If 8, then 800,000.

>      long i, j;
>      FILE *fp;
>
>      fp = fopen("shoulder.wmv", "rb+");
>
>      for (i = 0; i < SIZE; ++i) {
>         a[i] = 0;
>      }
>
>      for (j = 0; j < 7000000; ++j) {
>         c = fgetc(fp);
>
>         if (c != EOF) {
>
>             a[counter] = c;

Depending on the size of your file, this could easily exceed the
amount of space reserved for a.  When that happens, your program
exhibits undefined behavior.

Why are you using a long to store a character?

>             counter++;
>         } else {
>             for (i = 0; i < 100; ++i) {
>                 printf("i and frequency is %ld   %ld\n", i, a[i]);

This code does not compute any frequencies.  Any non-zero a[i] has had
its value changed exactly once and the value is set to the i-th
character in the file.

>             }
>
>             break;
>         }
>      }
>      printf("Counter reached %ld\n", counter);
>      fclose(fp);
>      return 0;
>
> }
>
> // cc -Wall -Wextra hist1.c -o hist
> $
>
> So, why the seg fault?
> --
> Uno

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

#5890

On 06/12/2011 01:05 AM, Barry Schwarz wrote:
> On Jun 11, 11:06 pm, Uno<U...@example.invalid>  wrote:
>> $ indent -kr hist1.c
>> $ cc -Wall -Wextra hist1.c -o hist
>> $ ./hist
>> Segmentation fault
>> $ cat hist1.c
>> #include<stdio.h>
>> #define SIZE 100000
>>
>> int main(void)
>> {
>>       int c;
>>       long counter = 0;
>>       long a[SIZE];
>
> If long is 4 bytes, this reserves 400,000 bytes.  If 8, then 800,000.

I'm sure I have a gig of memory.
>
>>       long i, j;
>>       FILE *fp;
>>
>>       fp = fopen("shoulder.wmv", "rb+");
>>
>>       for (i = 0; i<  SIZE; ++i) {
>>          a[i] = 0;
>>       }
>>
>>       for (j = 0; j<  7000000; ++j) {
>>          c = fgetc(fp);
>>
>>          if (c != EOF) {
>>
>>              a[counter] = c;
>
> Depending on the size of your file, this could easily exceed the
> amount of space reserved for a.  When that happens, your program
> exhibits undefined behavior.

I've tried different values here, but 20 million is greater than 19 and 
change.

-rw-r--r-- 1 dan dan 19573712 2011-06-05 17:32 shoulder.wmv
$ cc -Wall -Wextra hist2.c -o hist
$ ./hist
Segmentation fault
$ cat hist2.c
#include <stdio.h>
#define SIZE 20000000

int main(void)
{
     int c;
     long counter = 0;
     long a[SIZE];
     long i, j;
     FILE *fp;

     fp = fopen("shoulder.wmv", "rb+");

     for (i = 0; i < SIZE; ++i) {
	a[i] = 0;
     }

     for (j = 0; j < SIZE; ++j) {
	c = fgetc(fp);

         //printf("c is %d\n", c);


	if (c != EOF) {

	    a[counter] = c;
	    counter++;
	} else {
	    for (i = 0; i < 100; ++i) {
		printf("i and frequency is %ld   %ld\n", i, a[i]);
	    }


	    break;
	}
     }
     printf("Counter reached %ld\n", counter);
     fclose(fp);
     return 0;
}

// cc -Wall -Wextra hist2.c -o hist
$


>
> Why are you using a long to store a character?

A long is intended to store the frequency of a given char.
>
>>              counter++;
>>          } else {
>>              for (i = 0; i<  100; ++i) {
>>                  printf("i and frequency is %ld   %ld\n", i, a[i]);
>
> This code does not compute any frequencies.  Any non-zero a[i] has had
> its value changed exactly once and the value is set to the i-th
> character in the file.

This code hasn't done anything yet; that is true.
-- 
Uno

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

#5897

Uno wrote:
> On 06/12/2011 01:05 AM, Barry Schwarz wrote:
>> On Jun 11, 11:06 pm, Uno<U...@example.invalid>  wrote:
>>> $ indent -kr hist1.c
>>> $ cc -Wall -Wextra hist1.c -o hist
>>> $ ./hist
>>> Segmentation fault
>>> $ cat hist1.c
>>> #include<stdio.h>
>>> #define SIZE 100000
>>>
>>> int main(void)
>>> {
>>>       int c;
>>>       long counter = 0;
>>>       long a[SIZE];
>>
>> If long is 4 bytes, this reserves 400,000 bytes.  If 8, then 800,000.
>
> I'm sure I have a gig of memory.

But you're not using it for long a[SIZE], so accessing a[SIZE+1] would 
result in a SIGSEGV usually.

>>
>>>       long i, j;
>>>       FILE *fp;
>>>
>>>       fp = fopen("shoulder.wmv", "rb+");
>>>
>>>       for (i = 0; i<  SIZE; ++i) {
>>>          a[i] = 0;
>>>       }
>>>
>>>       for (j = 0; j<  7000000; ++j) {
>>>          c = fgetc(fp);
>>>
>>>          if (c != EOF) {
>>>
>>>              a[counter] = c;
>>
>> Depending on the size of your file, this could easily exceed the
>> amount of space reserved for a.  When that happens, your program
>> exhibits undefined behavior.
>
> I've tried different values here, but 20 million is greater than 19
> and change.
>
> -rw-r--r-- 1 dan dan 19573712 2011-06-05 17:32 shoulder.wmv
> $ cc -Wall -Wextra hist2.c -o hist
> $ ./hist
> Segmentation fault
> $ cat hist2.c
> #include <stdio.h>
> #define SIZE 20000000
>
> int main(void)
> {
>     int c;
>     long counter = 0;
>     long a[SIZE];
>     long i, j;
>     FILE *fp;
>
>     fp = fopen("shoulder.wmv", "rb+");
>
>     for (i = 0; i < SIZE; ++i) {
> a[i] = 0;
>     }
>
>     for (j = 0; j < SIZE; ++j) {
> c = fgetc(fp);
>
>         //printf("c is %d\n", c);
>
>
> if (c != EOF) {
>
>     a[counter] = c;
>     counter++;
> } else {
>     for (i = 0; i < 100; ++i) {
> printf("i and frequency is %ld   %ld\n", i, a[i]);
>     }
>
>
>     break;
> }
>     }
>     printf("Counter reached %ld\n", counter);
>     fclose(fp);
>     return 0;
> }
>
> // cc -Wall -Wextra hist2.c -o hist
> $
>
>
>>
>> Why are you using a long to store a character?
>
> A long is intended to store the frequency of a given char.
>>
>>>              counter++;
>>>          } else {
>>>              for (i = 0; i<  100; ++i) {
>>>                  printf("i and frequency is %ld   %ld\n", i, a[i]);
>>
>> This code does not compute any frequencies.  Any non-zero a[i] has
>> had its value changed exactly once and the value is set to the i-th
>> character in the file.
>
> This code hasn't done anything yet; that is true.

Have you tried using a debugger on this? Where does the debugger report the 
program to fail?
You probably want to add -g to the compiler options.

Bye, Jojo 

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

#5909

Uno <Uno@example.invalid> writes:

> On 06/12/2011 01:05 AM, Barry Schwarz wrote:
>> On Jun 11, 11:06 pm, Uno<U...@example.invalid>  wrote:
>>> $ indent -kr hist1.c
>>> $ cc -Wall -Wextra hist1.c -o hist
>>> $ ./hist
>>> Segmentation fault
>>> $ cat hist1.c
>>> #include<stdio.h>
>>> #define SIZE 100000
>>>
>>> int main(void)
>>> {
>>>       int c;
>>>       long counter = 0;
>>>       long a[SIZE];
>>
>> If long is 4 bytes, this reserves 400,000 bytes.  If 8, then 800,000.
>
> I'm sure I have a gig of memory.

That doesn't mean your array is a gig long; your array is only as long
as you made it.

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

#5898

On 2011-06-12, Uno <Uno@example.invalid> wrote:
> $ indent -kr hist1.c
> $ cc -Wall -Wextra hist1.c -o hist
> $ ./hist
> Segmentation fault
> $ cat hist1.c
> #include <stdio.h>
> #define SIZE 100000
>
> int main(void)
> {
>      int c;
>      long counter = 0;
>      long a[SIZE];
>      long i, j;
>      FILE *fp;
>
>      fp = fopen("shoulder.wmv", "rb+");
>
>      for (i = 0; i < SIZE; ++i) {
> 	a[i] = 0;
>      }
>
>      for (j = 0; j < 7000000; ++j) {
> 	c = fgetc(fp);
>
>
> 	if (c != EOF) {
>
> 	    a[counter] = c;
> 	    counter++;
> 	} else {
> 	    for (i = 0; i < 100; ++i) {
> 		printf("i and frequency is %ld   %ld\n", i, a[i]);
> 	    }
>
>
> 	    break;
> 	}
>      }
>      printf("Counter reached %ld\n", counter);
>      fclose(fp);
>      return 0;
> }
>
> // cc -Wall -Wextra hist1.c -o hist

Don't repeat yourself.

> $
>
> So, why the seg fault?

Is shoulder.wmv more than SIZE bytes long?

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

#5900

On 6/12/2011 2:06 AM, Uno wrote:

> #define SIZE 100000
> [...]
> long a[SIZE];
> [...]
> for (j = 0; j < 7000000; ++j) {
> [...]
> So, why the seg fault?

     Choose the phrase that most accurately completes this statement:
"7000000 is ________ 100000."

     a) less than
     b) greater than
     c) equal to
     d) more equal to
     e) more tweeted than

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#6040

On 12 jun, 14:23, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> On 6/12/2011 2:06 AM, Uno wrote:
>
> > #define SIZE 100000
> > [...]
> > long a[SIZE];
> > [...]
> > for (j = 0; j < 7000000; ++j) {
> > [...]
> > So, why the seg fault?
>
>      Choose the phrase that most accurately completes this statement:
> "7000000 is ________ 100000."
>
>      a) less than
>      b) greater than
>      c) equal to
>      d) more equal to
>      e) more tweeted than
>
> --
> Eric Sosman
> esos...@ieee-dot-org.invalid

Quite right, though I doubt the OP understands why you came up with
this little quiz question.
The OP ought to learn the difference between learning C (or any other
programming language)
and programming... Once that is understood he will not only answer
your question correctly but
understand why you put it that way.
Hans

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

#6706

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

> On 6/12/2011 2:06 AM, Uno wrote:
>
>> #define SIZE 100000
>> [...]
>> long a[SIZE];
>> [...]
>> for (j = 0; j < 7000000; ++j) {
>> [...]
>> So, why the seg fault?
>
>     Choose the phrase that most accurately completes this statement:
> "7000000 is ________ 100000."
>
>     a) less than
>     b) greater than
>     c) equal to
>     d) more equal to
>     e) more tweeted than

Great answer!  Definitely deserves a "Best in thread"
award.

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

#5902

"Uno" <Uno@example.invalid> wrote in message 
news:95j3bgFj2qU1@mid.individual.net...

> c = fgetc(fp);
>
>
> if (c != EOF) {
>
>     a[counter] = c;

  Try:
   ++a[c];

here if trying to count frequency of each character.

Up above, you might need something like:

 long a[256]={0};

-- 
Bartc 

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

#5908

Uno <Uno@example.invalid> writes:
> So, why the seg fault?

Let's just say this code is a prime example of why I took points of on
student programs that had magic numbers (like 7000000 for instance) in
the executable code.

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

#5916

On 06/12/2011 10:24 AM, Joe Pfeiffer wrote:
> Uno<Uno@example.invalid>  writes:
>> So, why the seg fault?
>
> Let's just say this code is a prime example of why I took points of on
> student programs that had magic numbers (like 7000000 for instance) in
> the executable code.
>

There were a lot of problems with this source that needing ironing out, 
and I needed to start to somehwhere.  When I've got a program that 
compiles, I like to have the magic numbers #defined.  I haven't really 
done much C on a 64-bit processor, so my ballparking seems to be wanting.

$  cc -Wall -Wextra -g hist3.c -o hist
$ ./hist
UCHAR_MAX + 1 is 256
a[0] is 217337
a[1] is 123676
a[2] is 137894
a[3] is 100155
...
a[252] is 97099
a[253] is 75547
a[254] is 113450
a[255] is 128194
Counter reached 19573713
Counter2 reached 19573712
$ cat hist3.c
#include <stdio.h>
#include <limits.h>
#define SIZE 20000000
#define SIZE2 (UCHAR_MAX+1)

int main(void)
{
     int c;
     long counter = 0;
     long counter2 = 0;
     long a[SIZE2];
     long i, j;
     FILE *fp;
     fp = fopen("shoulder.wmv", "rb+");
     printf("UCHAR_MAX + 1 is %d\n", SIZE2);
     for (i = 0; i < (SIZE2); ++i) {
	a[i] = 0;
     }
     for (j = 0; j < SIZE; ++j) {
	c = fgetc(fp);
	counter++;
	if (c != EOF) {
	    a[c] = ++a[c];
	} else
	    break;
     }
     for (i = 0; i < (SIZE2); ++i) {
	printf("a[%ld] is %ld\n", i, a[i]);
	counter2 = counter2 + a[i];
     }
     printf("Counter reached %ld\n", counter);
     printf("Counter2 reached %ld\n", counter2);
     fclose(fp);
     return 0;
}

// cc -Wall -Wextra -g hist3.c -o hist
$

I needed two different SIZES, one that would be larger than the byte 
count of the file to be read and another that was one greater than 
UCHAR_MAX.  Seems to behave.  Thanks all for comments.
-- 
Uno

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

#5921

"Uno" <Uno@example.invalid> wrote in message 
news:95kmvoFn2bU1@mid.individual.net...

>     a[c] = ++a[c];

I think just:

 ++a[c];

will do here, since ++ also modifies it's operand as well as return it's 
value plus 1.

-- 
Bartc

 

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

#5923

"BartC" <bc@freeuk.com> writes:
> "Uno" <Uno@example.invalid> wrote in message 
> news:95kmvoFn2bU1@mid.individual.net...
>
>>     a[c] = ++a[c];
>
> I think just:
>
>  ++a[c];
>
> will do here, since ++ also modifies it's operand as well as return it's 
> value plus 1.

In fact the behavior of a[c] = ++a[c] is undefined, since it modifies
a[c] twice without an intervening sequence point.

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

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

#5928

On 06/12/2011 03:29 PM, Keith Thompson wrote:
> "BartC"<bc@freeuk.com>  writes:
>> "Uno"<Uno@example.invalid>  wrote in message
>> news:95kmvoFn2bU1@mid.individual.net...
>>
>>>      a[c] = ++a[c];
>>
>> I think just:
>>
>>   ++a[c];
>>
>> will do here, since ++ also modifies it's operand as well as return it's
>> value plus 1.
>
> In fact the behavior of a[c] = ++a[c] is undefined, since it modifies
> a[c] twice without an intervening sequence point.
>

I changed that.  So now I'm trying to get the data in a dynamic array:

$ indent -i3 hist7.c
$ cc -Wall -Wextra hist7.c -o hist
$ ./hist
file_length is 19573712
a[245] is 50064
a[246] is 38224
a[247] is 58741
a[248] is 92306
a[249] is 58773
a[250] is 65617
a[251] is 41401
a[252] is 97099
a[253] is 75547
a[254] is 113450
a[255] is 128194
counter2 reached 819416
counter reached 19573713
execution makes it this far
b[245] is 50064
b[246] is 38224
b[247] is 58741
b[248] is 92306
b[249] is 58773
b[250] is 65617
b[251] is 41401
b[252] is 97099
b[253] is 75547
b[254] is 113450
b[255] is 128194
counter3 reached 819416
$ cat hist7.c
#include <stdio.h>
#include <limits.h>
#include <stdlib.h>
#define SIZE 20000000
#define SIZE2 (UCHAR_MAX+1)

int
main (void)
{
    int c;
    long counter = 0;
    long counter2 = 0;
    long counter3 = 0;
    long a[SIZE2], b[SIZE2];
    long i, j, end;
    FILE *fp;
    char filename[] = "shoulder.wmv";
    unsigned char *p;

    fp = fopen (filename, "rb+");
    fseek (fp, 0L, SEEK_END);
    end = ftell (fp);
    fseek (fp, 0L, SEEK_SET);
    printf ("file_length is %ld\n", end);
    p = malloc (end);

    for (i = 0; i < (SIZE2); ++i)
      {
	a[i] = 0;
      }
    for (j = 0; j < SIZE; ++j)
      {
	c = fgetc (fp);
	counter++;
	if (c != EOF)
	  {
	     p[j] = c;
	     ++a[c];
	  }
	else
	   break;
      }
    for (i = 245; i < (SIZE2); ++i)
      {
	printf ("a[%ld] is %ld\n", i, a[i]);
	counter2 = counter2 + a[i];
      }
    printf ("counter2 reached %ld\n", counter2);
    printf ("counter reached %ld\n", counter);
    for (i = 0; i < SIZE2; ++i)
      {
	b[i] = 0;
      }
    printf ("execution makes it this far\n");
    for (j = 0; j < end; ++j)
      {
	c = p[j];
	++b[c];
      }

    for (i = 245; i < (SIZE2); ++i)
      {
	printf ("b[%ld] is %ld\n", i, b[i]);
	counter3 = counter3 + b[i];
      }
    printf ("counter3 reached %ld\n", counter3);
    fclose (fp);
    return 0;
}

// cc -Wall -Wextra hist7.c -o hist
$

Does the malloc'ing look good for reading this file?  Also, what do 
POSIX and C say about the EOF character itself?  If my data are typical, 
I would say that neither thinks that EOF is part of the file.

(Because it's pentecost)  Yabba-daba-doo!
-- 
Uno

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

#5932

Uno <Uno@example.invalid> writes:

>> "BartC"<bc@freeuk.com>  writes:
>>> "Uno"<Uno@example.invalid>  wrote in message
>>> news:95kmvoFn2bU1@mid.individual.net...
>>>
>>>>      a[c] = ++a[c];
>>>
>>> I think just:
>>>
>>>   ++a[c];
>>>
>>> will do here, since ++ also modifies it's operand as well as return it's
>>> value plus 1.
>>
>> In fact the behavior of a[c] = ++a[c] is undefined, since it modifies
>> a[c] twice without an intervening sequence point.
>>
>
> I changed that.  So now I'm trying to get the data in a dynamic array:

And do what with it?

> $ indent -i3 hist7.c
[...]
> $ cat hist7.c
> #include <stdio.h>
> #include <limits.h>
> #include <stdlib.h>
> #define SIZE 20000000
> #define SIZE2 (UCHAR_MAX+1)
>
> int
> main (void)
> {
>     int c;
>     long counter = 0;
>     long counter2 = 0;
>     long counter3 = 0;
>     long a[SIZE2], b[SIZE2];
>     long i, j, end;
>     FILE *fp;
>     char filename[] = "shoulder.wmv";
>     unsigned char *p;
>
>     fp = fopen (filename, "rb+");
>     fseek (fp, 0L, SEEK_END);
>     end = ftell (fp);
>     fseek (fp, 0L, SEEK_SET);
>     printf ("file_length is %ld\n", end);
>     p = malloc (end);

You don't check whether malloc() succeeded.  (Don't bother telling
us how much memory you have; just check whether p==NULL.)

Note that the fseek() method isn't guaranteed to tell you the size
of the file.  It probably does so on your system, but the standard
doesn't guarantee it.

(And as long as your code is non-portable, you probably might as well
use some non-portable method like fstat().)

If it works on your system, and if you're sufficiently sure that
the file's size won't change while the program is running, that's
probably ok.

>     for (i = 0; i < (SIZE2); ++i)
>       {
> 	a[i] = 0;
>       }
>     for (j = 0; j < SIZE; ++j)
>       {
> 	c = fgetc (fp);
> 	counter++;

You increment counter even when fgetc() returns EOF?  I don't know what
you're counting, so I can't tell whether that's right or not.

> 	if (c != EOF)
> 	  {
> 	     p[j] = c;
> 	     ++a[c];
> 	  }
> 	else
> 	   break;
>       }
[snip]
>
> // cc -Wall -Wextra hist7.c -o hist
> $
>
> Does the malloc'ing look good for reading this file?  Also, what do 
> POSIX and C say about the EOF character itself?  If my data are typical, 
> I would say that neither thinks that EOF is part of the file.

There is no "EOF character".  fgetc() returns *either* the value
of the character it just read (treated as an unsigned char and
converted to int) *or* the special value EOF if it was unable to
read a character.

Typically UCHAR_MAX==255 (it could be larger) and EOF==-1 (it can
be any negative int value).  So fgetc() will return either a value
in the range 0..255, or the value -1.

No, EOF is not part of the file; it's an indication that there's
nothing more in the file, or that there was an error.  You can call
feof() and/or ferror() to determine which.

Do you really need to read the entire file into memory?  Perhaps you
do, but it's often better to process the data as you're reading it.
It depends on what your goal is.

[...]

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

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

#5944

On 06/12/2011 05:14 PM, Keith Thompson wrote:
> Uno<Uno@example.invalid>  writes:

>> I changed that.  So now I'm trying to get the data in a dynamic array:
>
> And do what with it?

Pass it to a common C extension.
>
>> $ indent -i3 hist7.c
> [...]
>> $ cat hist7.c
>> #include<stdio.h>
>> #include<limits.h>
>> #include<stdlib.h>
>> #define SIZE 20000000
>> #define SIZE2 (UCHAR_MAX+1)
>>
>> int
>> main (void)
>> {
>>      int c;
>>      long counter = 0;
>>      long counter2 = 0;
>>      long counter3 = 0;
>>      long a[SIZE2], b[SIZE2];
>>      long i, j, end;
>>      FILE *fp;
>>      char filename[] = "shoulder.wmv";
>>      unsigned char *p;
>>
>>      fp = fopen (filename, "rb+");
>>      fseek (fp, 0L, SEEK_END);
>>      end = ftell (fp);
>>      fseek (fp, 0L, SEEK_SET);
>>      printf ("file_length is %ld\n", end);
>>      p = malloc (end);
>
> You don't check whether malloc() succeeded.  (Don't bother telling
> us how much memory you have; just check whether p==NULL.)
>
> Note that the fseek() method isn't guaranteed to tell you the size
> of the file.  It probably does so on your system, but the standard
> doesn't guarantee it.
>
> (And as long as your code is non-portable, you probably might as well
> use some non-portable method like fstat().)
>
> If it works on your system, and if you're sufficiently sure that
> the file's size won't change while the program is running, that's
> probably ok.

This is my latest version that uses non-portable aspects of my platform:

[sorry, could only paste as quotation]

> $ cc -Wall -Wextra hist9.c -o hist
> hist9.c: In function ‘main’:
> hist9.c:17: warning: unused variable ‘a’
> hist9.c:15: warning: unused variable ‘counter2’
> hist9.c:14: warning: unused variable ‘counter’
> $ ./hist
> file_length is 19573712
> Main control
> b[245] is 50064
> b[246] is 38224
> b[247] is 58741
> b[248] is 92306
> b[249] is 58773
> b[250] is 65617
> b[251] is 41401
> b[252] is 97099
> b[253] is 75547
> b[254] is 113450
> b[255] is 128194
> counter3 reached 819416
> file_length is 19573712
> $ cat hist9.c
> #include <stdio.h>
> #include <limits.h>
> #include <stdlib.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <unistd.h>
>
> #define SIZE2 (UCHAR_MAX+1)
>
> int
> main (void)
> {
>    int c;
>    long counter = 0;
>    long counter2 = 0;
>    long counter3 = 0;
>    long a[SIZE2], b[SIZE2];
>    long i, j, end, size;
>    FILE *fp;
>    char filename[] = "shoulder.wmv";
>    unsigned char *p;
>    struct stat st;
>
>    fp = fopen (filename, "rb+");
>    fseek (fp, 0L, SEEK_END);
>    end = ftell (fp);
>    fseek (fp, 0L, SEEK_SET);
>    printf ("file_length is %ld\n", end);
>    p = malloc (end);
>    if (p == NULL)
>      {
> 	printf ("malloc failed.\n");
> 	exit (EXIT_FAILURE);
>      }
>    for (i = 0; i < SIZE2; ++i)
>      {
> 	b[i] = 0;
>      }
>    printf ("Main control\n");
>    for (j = 0; j < end; ++j)
>      {
> 	c = fgetc (fp);
> 	if (c != EOF)
> 	  {
> 	     p[j] = c;
> 	     ++b[c];
> 	  }
> 	else
> 	   break;
>      }
> // a little output
>    for (i = 245; i < SIZE2; ++i)
>      {
> 	printf ("b[%ld] is %ld\n", i, b[i]);
> 	counter3 = counter3 + b[i];
>      }
>    printf ("counter3 reached %ld\n", counter3);
>
> // stat
>
>    stat (filename, &st);
>    size = st.st_size;
>    printf ("file_length is %ld\n", size);
>
>    fclose (fp);
>    return 0;
> }
>
> // cc -Wall -Wextra hist9.c -o hist
> $

[snip]
>> Does the malloc'ing look good for reading this file?  Also, what do
>> POSIX and C say about the EOF character itself?  If my data are typical,
>> I would say that neither thinks that EOF is part of the file.
>
> There is no "EOF character".  fgetc() returns *either* the value
> of the character it just read (treated as an unsigned char and
> converted to int) *or* the special value EOF if it was unable to
> read a character.
>
> Typically UCHAR_MAX==255 (it could be larger) and EOF==-1 (it can
> be any negative int value).  So fgetc() will return either a value
> in the range 0..255, or the value -1.
>
> No, EOF is not part of the file; it's an indication that there's
> nothing more in the file, or that there was an error.  You can call
> feof() and/or ferror() to determine which.
>
> Do you really need to read the entire file into memory?  Perhaps you
> do, but it's often better to process the data as you're reading it.
> It depends on what your goal is.

Ok, good, that seems to square with my recollection and data.  Cheers,
-- 
Uno

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

#5926

On 6/12/2011 4:47 PM, Uno wrote:
>
> There were a lot of problems with this source that needing ironing out,
> and I needed to start to somehwhere.

     An *excellent* place to start is with a description of what
you want the program to do.  As it is, you've just thrown a bunch
of code at us and expected us to divine your intentions.  If the
code were not so clearly broken, divination might stand a chance;
even then it would be better to state your purpose.  With broken
code, such a statement is even more important.

> When I've got a program that
> compiles, I like to have the magic numbers #defined.

     Your choice, but you're making extra work for yourself.  When
you're replacing numeric constants with macro names and you come
across a 3, should you change it to SHIFTS_PER_DAY or to VERSION?
Essentially, you've created a reverse-engineering problem for yourself,
giving yourself an extra opportunity to make misteaks.

> I haven't really
> done much C on a 64-bit processor, so my ballparking seems to be wanting.

     Nothing in your code stands out as bitness-related.

> #include <stdio.h>
> #include <limits.h>
> #define SIZE 20000000
> #define SIZE2 (UCHAR_MAX+1)
>
> int main(void)
> {
>     int c;
>     long counter = 0;
>     long counter2 = 0;
>     long a[SIZE2];
>     long i, j;
>     FILE *fp;
>     fp = fopen("shoulder.wmv", "rb+");

     Why the "+", since you never write to the file?  And why
is there still no check for failure, after others have already
pointed out the lack?

>     printf("UCHAR_MAX + 1 is %d\n", SIZE2);
>     for (i = 0; i < (SIZE2); ++i) {

     The parentheses around SIZE2 are harmless, but not helpful:
They're just unnecessary clutter that gives the reader more to
parse.  Perhaps you think they're necessary because SIZE2 expands
to an expression rather than to a single token?  But the expression
is already parenthesized (as good macros should be), so tacking on
an extra layer isn't needed.  What you've written is equivalent to

	for (i = 0; i < ((UCHAR_MAX+1)); ++i)

>     a[i] = 0;
>     }
>     for (j = 0; j < SIZE; ++j) {
>     c = fgetc(fp);
>     counter++;
>     if (c != EOF) {
>         a[c] = ++a[c];

     Undefined behavior: Two modifications of the same object
with no intervening sequence point.

>     } else
>         break;
>     }
>     for (i = 0; i < (SIZE2); ++i) {
>     printf("a[%ld] is %ld\n", i, a[i]);
>     counter2 = counter2 + a[i];
>     }
>     printf("Counter reached %ld\n", counter);
>     printf("Counter2 reached %ld\n", counter2);
>     fclose(fp);
>     return 0;
> }
>
> // cc -Wall -Wextra -g hist3.c -o hist
> $
>
> I needed two different SIZES, one that would be larger than the byte
> count of the file to be read and another that was one greater than
> UCHAR_MAX.

     SIZE2 (or equivalent) is necessary, yes.  But SIZE seems to
serve no useful purpose -- unless, as mentioned above, you have
purposes that aren't stated.

> Seems to behave.

     "Things are seldom what they seem.
      Skim milk masquerades as cream ..."

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

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

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

csiph-web