looking at binary files with C
Uno
$ 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
Ian Collins
> $ 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
Uno
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
Barry Schwarz
> $ 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.
Uno
> 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
Joachim Schmitz
> 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.
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
Ike Naar
Don't repeat yourself.
> $
>
> So, why the seg fault?
Is shoulder.wmv more than SIZE bytes long?
Eric Sosman
> #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
eso...@ieee-dot-org.invalid
BartC
news:95j3bg...@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
Joe Pfeiffer
> 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.
Joe Pfeiffer
> 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.
Uno
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
BartC
> 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
Keith Thompson
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) ks...@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"
Eric Sosman
>
> 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
eso...@ieee-dot-org.invalid
Uno
> "BartC"<b...@freeuk.com> writes:
>> "Uno"<U...@example.invalid> wrote in message
>> news:95kmvo...@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
Uno
> 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.
It takes me a few posts before I get a syntactical C program to use to
describe what I'm doing. Without referent source, I can't communicate this.
>
>> 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.
But you did notice that I have
#define SIZE2 (UCHAR_MAX+1)
, and this was the seg fault I couldn't get my head around when I first
posted.
>
>> 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.
A client paid me to put a binary file on the net, and I used perl's
net::ftp without knowing that I had to call the binary method in order
to upload without *nix eating ascii 13. (Thx a lot c.l.p.misc: for
nothing.)
I knew by comparing what I uploaded to what I downloaded, I would find
the problem. Others, for example, Alan Curry, might claim that *they*
found the problem, and I do not dispute that.
>
>> #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?
The + on all opens because I might want to write to them. No check for
failure because the only one I've got in my head is
or die "death $@\n"; Is there a K&R2 reference for how to do it?
>
>> 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.
Fixed that. Thx.
>
>> } 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.
Right, so I'm looking for your comment on the dynamic allocation which I
posted as a reply to keith.
>
>> Seems to behave.
>
> "Things are seldom what they seem.
> Skim milk masquerades as cream ..."
>
Arizona on fire.
Brewer raises my ire.
Of C I don't tire.
--
Uno
Keith Thompson
>> "BartC"<b...@freeuk.com> writes:
>>> "Uno"<U...@example.invalid> wrote in message
>>> news:95kmvo...@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
> On 06/12/2011 03:42 PM, Eric Sosman wrote:
>> 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.
>
> It takes me a few posts before I get a syntactical C program to use to
> describe what I'm doing. Without referent source, I can't communicate
> this.
You should be able to describe it in English. If you can't, I suggest
that you don't really know what you're doing.
Uno
> Uno<U...@example.invalid> writes:
>> On 06/12/2011 03:42 PM, Eric Sosman wrote:
>>> 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.
>>
>> It takes me a few posts before I get a syntactical C program to use to
>> describe what I'm doing. Without referent source, I can't communicate
>> this.
> [...]
>
> You should be able to describe it in English. If you can't, I suggest
> that you don't really know what you're doing.
>
My english is fine, keith, thx for caring.
--
Uno
Ian Collins
thx?
--
Ian Collins
Geoff
wrote:
>> My english is fine, keith, thx for caring.
>
>thx?
Trademark (in caps) THX. The trade name for an audio system developed
at Lucasfilm. Named after George Lucas's first film, "THX 1138". ;)
Joe Pfeiffer
> On 06/12/2011 10:24 AM, Joe Pfeiffer wrote:
>> Uno<U...@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.
Note that if you had done this earlier in the process, your mystery
segfault wouldn't have happened, saving you and everybody else some
time.
Uno
> Uno<U...@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.
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
James Waldby
...
> #define SIZE 20000000
...
> for (j = 0; j < SIZE; ++j) {
> c = fgetc(fp);
> counter++;
> if (c != EOF) {
> a[c] = ++a[c];
> } else
> break;
> }
That code is quite ugly and limited (value of SIZE is irrelevantly
based on a specific file's size), besides having the undefined-
behavior problem that other posters mentioned, in "a[c] = ++a[c]".
I suggest that you instead use code like the following:
while (1) {
c = fgetc(fp);
if (c == EOF) break;
++a[c];
++counter;
}
Some people prefer to do the read and EOF test in one line:
if ((c = fgetc(fp)) == EOF) break;
--
jiw
Uno
> That code is quite ugly and limited (value of SIZE is irrelevantly
> based on a specific file's size), besides having the undefined-
> behavior problem that other posters mentioned, in "a[c] = ++a[c]".
> I suggest that you instead use code like the following:
>
> while (1) {
> c = fgetc(fp);
> if (c == EOF) break;
> ++a[c];
> ++counter;
> }
>
> Some people prefer to do the read and EOF test in one line:
> if ((c = fgetc(fp)) == EOF) break;
>
Thx, james, I like the main control a lot better now:
$ cc -Wall -Wextra hist10.c -o hist
hist10.c: In function ‘main’:
hist10.c:18: warning: unused variable ‘j’
hist10.c:17: warning: unused variable ‘a’
hist10.c:15: warning: unused variable ‘counter2’
$ cat hist10.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");
while (1){
c = fgetc (fp);
if (c == EOF) break;
p[counter++] = c;
++b[c];
}
// 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 hist10.c -o hist
$ ./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
$
--
Uno
Eric Sosman
> On 06/12/2011 03:42 PM, Eric Sosman wrote:
>> 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.
>
> It takes me a few posts before I get a syntactical C program to use to
> describe what I'm doing. Without referent source, I can't communicate this.
If you cannot say what you want your program to do, neither
you nor anyone else can say whether it fulfills your purposes.
>>> 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.
>
> But you did notice that I have
> #define SIZE2 (UCHAR_MAX+1)
> , and this was the seg fault I couldn't get my head around when I first
> posted.
No, it had nothing to do with the matter.
> A client paid me
(!)
> to put a binary file on the net, and I used perl's
> net::ftp without knowing that I had to call the binary method in order
> to upload without *nix eating ascii 13. (Thx a lot c.l.p.misc: for
> nothing.)
Let me get this straight: You are upset with comp.lang.c for
failing to tell you how to use Perl correctly? Before we were even
aware you were trying to do anything?
>>> 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?
>
> The + on all opens because I might want to write to them.
Foolish. On some systems, wasteful.
> No check for
> failure because the only one I've got in my head is
> or die "death $@\n"; Is there a K&R2 reference for how to do it?
After the call and assignment, check whether `fp' is NULL.
If it's not, fopen() succeeded and you're ready to do I/O on
the stream `fp' points to. If it's NULL, fopen() failed and you
should take alternative action. Even if the alternative action
amounts to nothing more than "I give up," it will at least be a
predictable response. Just plowing ahead as if everything were
fine produces unpredictable results: Quite likely a SIGSEGV, but
not necessarily anything that benign.
>>> 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.
>
> Right, so I'm looking for your comment on the dynamic allocation which I
> posted as a reply to keith.
Since you are collecting payment for the program comp.lang.c
is more or less writing for you, perhaps you should offer the
forum a percentage. Until then, no more free comments.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Seebs
> You should be able to describe it in English. If you can't, I suggest
> that you don't really know what you're doing.
Going by his posting history, I think your evaluation may be
misleading. You are assuming a kind of baseline lucidity such that
"know what you're doing" makes sense, and I just plain don't see
the justification for this assumption.
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet...@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.
Keith Thompson
If you're using the same C code both as your requirements
specification and as your implementation, then congratulations,
you're done! By definition, the program does what it does. If your
code has a syntax error, we can only assume that your goal is to
produce compiler error messages.
If you can't describe what you want to do in English (or whatever
your native language happens to be), then you don't know what you
want to do. (If you can but won't, we can assume you don't really
want any help.)
Uno
> On 2011-06-12, Keith Thompson<ks...@mib.org> wrote:
>> You should be able to describe it in English. If you can't, I suggest
>> that you don't really know what you're doing.
>
> Going by his posting history, I think your evaluation may be
> misleading. You are assuming a kind of baseline lucidity such that
> "know what you're doing" makes sense, and I just plain don't see
> the justification for this assumption.
>
> -s
I'm looking at binary files with C. Read the fucking subject.
Now that you've come on to my thread, I'm gonna go somewhere where
there's less eurotrash.
--
Uno
Uno
> On 6/12/2011 7:01 PM, Uno wrote:
>> On 06/12/2011 03:42 PM, Eric Sosman wrote:
>>> 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.
>>
>> It takes me a few posts before I get a syntactical C program to use to
>> describe what I'm doing. Without referent source, I can't communicate
>> this.
>
> If you cannot say what you want your program to do, neither
> you nor anyone else can say whether it fulfills your purposes.
The program that I have farthest downthread is pretty close to what I
came in the door for. I thought it counted as a virtue around here not
to bring up the mixed-language programming and how standard C fits into
the whole.
>
>>>> 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.
>>
>> But you did notice that I have
>> #define SIZE2 (UCHAR_MAX+1)
>> , and this was the seg fault I couldn't get my head around when I first
>> posted.
>
> No, it had nothing to do with the matter.
>
>> A client paid me
>
> (!)
It is only due to a family emergency that I've been asked to do this. I
simply stipulated to them that if I did computer work for them, they
would have to give me what I would earned out doing my thing otherwise.
They accidentally paid my gas bill instead of where I told them, so I
got 3 years of gas for my efforts. (I'm very proud to have a gas bill
of $30 in february.)
>
>> to put a binary file on the net, and I used perl's
>> net::ftp without knowing that I had to call the binary method in order
>> to upload without *nix eating ascii 13. (Thx a lot c.l.p.misc: for
>> nothing.)
>
> Let me get this straight: You are upset with comp.lang.c for
> failing to tell you how to use Perl correctly? Before we were even
> aware you were trying to do anything?
No, you read incorrectly. The parenthetical expression was about
c.l.p.misc, which is chock of full of Seeb's and Cbfalconer's who really
aren't there to help or contribute beyond derision and being almost
always wrong.
>
>>>> 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?
>>
>> The + on all opens because I might want to write to them.
>
> Foolish. On some systems, wasteful.
Ok, I'll remove it.
>
>> No check for
>> failure because the only one I've got in my head is
>> or die "death $@\n"; Is there a K&R2 reference for how to do it?
>
> After the call and assignment, check whether `fp' is NULL.
> If it's not, fopen() succeeded and you're ready to do I/O on
> the stream `fp' points to. If it's NULL, fopen() failed and you
> should take alternative action. Even if the alternative action
> amounts to nothing more than "I give up," it will at least be a
> predictable response. Just plowing ahead as if everything were
> fine produces unpredictable results: Quite likely a SIGSEGV, but
> not necessarily anything that benign.
I think I've done that correctly now. I'm pretty close on most things,
but I need a nudge with others.
>
>>>> 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.
>>
>> Right, so I'm looking for your comment on the dynamic allocation which I
>> posted as a reply to keith.
>
> Since you are collecting payment for the program comp.lang.c
> is more or less writing for you, perhaps you should offer the
> forum a percentage. Until then, no more free comments.
>
You tend to chime in on the beginning of threads, which probably
behooves you. Cheers,
--
Uno
Keith Thompson
> On 06/13/2011 08:39 AM, Seebs wrote:
>> On 2011-06-12, Keith Thompson<ks...@mib.org> wrote:
>>> You should be able to describe it in English. If you can't, I suggest
>>> that you don't really know what you're doing.
>>
>> Going by his posting history, I think your evaluation may be
>> misleading. You are assuming a kind of baseline lucidity such that
>> "know what you're doing" makes sense, and I just plain don't see
>> the justification for this assumption.
>
>
> Now that you've come on to my thread, I'm gonna go somewhere where
> there's less eurotrash.
Thank you, Seebs!
Eric Sosman
> On 06/13/2011 05:57 AM, Eric Sosman wrote:
>> If you cannot say what you want your program to do, neither
>> you nor anyone else can say whether it fulfills your purposes.
>
> The program that I have farthest downthread is pretty close to what I
> came in the door for. I thought it counted as a virtue around here not
> to bring up the mixed-language programming and how standard C fits into
> the whole.
Okay. Your program fulfills every requirement, goal, wish,
hope, and dream you've expressed. The only mystery is: Why are
you asking comp.lang.c to suggest alterations to perfection?
>>> A client paid me
>>
>> (!)
>
> It is only due to a family emergency that I've been asked to do this. I
> simply stipulated to them that if I did computer work for them, they
> would have to give me what I would earned out doing my thing otherwise.
> They accidentally paid my gas bill instead of where I told them, so I
> got 3 years of gas for my efforts. (I'm very proud to have a gas bill of
> $30 in february.)
Somebody paid a thou for your services? P.T. Barnum's saying
comes instantly to mind.
> I think I've done that correctly now. I'm pretty close on most things,
> but I need a nudge with others.
A nudge with a clue-by-four, methinks. Uno, listen to me:
You have NO REASON to represent yourself as a competent programmer,
as a person whose programming services are deserving of pay, as a
person who has the slightest command of the tools you use so poorly.
This is not a judgement: We all start from a state of ignorance, and
learning our way out of it takes time and effort. If you expend the
effort and take the time, perhaps you will eventually learn. But at
the moment, you are NOT a C programmer, quite likely not an Anything
programmer, and passing yourself off as one is an act of fraud.
IANAL, and cannot say whether this particular species of fraud
is criminally or even civilly actionable. However, I'll relate a bit
of history: Some years ago I worked for a large company that had hired
a tiny company three or four times over a few years, spending maybe a
half million dollars for the benefit of their expertise. We hired them
again, and they sent us an "expert" who was in fact a learn-by-doing
rank beginner; this was exposed when he spent eleven days getting
nowhere on a problem I (a non-expert) then debugged in less than
twenty minutes.
We didn't take them to court. We just took them off the Approved
Contractors list, and never hired them again. Deprived of their
annual quarter-million, they were out of business within the year.
And my question to you, Uno, is: Do you want to be *that* expert?
--
Eric Sosman
eso...@ieee-dot-org.invalid
Hans Vlems
> 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?
>
> "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
Hans Vlems
Before trying to get a program compiled correctly you might need to
spend some time on design first.
Hans
lovecreatesbeauty
Hey main, can this version get paid?
$ cat a.c
#include <stdio.h>
#include <errno.h>
#include <stdlib.h>
#include <string.h>
#include <limits.h>
int main(void)
{
FILE *fp;
const char *file = "./intro.wmv";
int errno_copy;
int ch;
unsigned long char_set[UCHAR_MAX + 1] = {0};
errno = 0;
fp = fopen(file, "r");
errno_copy = errno;
if (!fp){
printf("%s %s\n", strerror(errno_copy), file);
return EXIT_FAILURE;
}
while ((ch = fgetc(fp)) != EOF){
char_set[ch]++;
}
fclose(fp);
for (ch = 0; ch != sizeof char_set / sizeof *char_set; ch++){
if (char_set[ch]){
printf("BYTE:%d CNT:%lu\n", ch, char_set[ch]);
}
}
return EXIT_SUCCESS;
}
$
io_x
"James Waldby" <n...@valid.invalid> ha scritto nel messaggio
news:it3od3$j3j$1...@dont-email.me...
> On Sun, 12 Jun 2011 14:47:49 -0600, Uno wrote:
> ...
>> #define SIZE 20000000
> ...
>> for (j = 0; j < SIZE; ++j) {
>> c = fgetc(fp);
>> counter++;
>> if (c != EOF) {
>> a[c] = ++a[c];
>> } else
>> break;
>> }
> ...
>
> That code is quite ugly and limited (value of SIZE is irrelevantly
> based on a specific file's size), besides having the undefined-
> behavior problem that other posters mentioned, in "a[c] = ++a[c]".
> I suggest that you instead use code like the following:
>
> while (1) {
> c = fgetc(fp);
> if (c == EOF) break;
> ++a[c];
> ++counter;
> }
this is my try, i know there will be error etc etc
i'm not perfect...
#include <stdio.h>
#include <stdint.h>
#include <limits.h>
// macro for types
#define u64 uint64_t
#define u32 uint32_t
#define u16 uint16_t
#define u8 uint8_t
// macro for function
#define P printf
// macro for keyWords
#define G goto
#define R return
#define W while
#define F for
int main(int c, char** a)
{u32 nc[256], i, cont;
FILE *pf;
if(sizeof(u32)!=sizeof(int)||CHAR_BIT!=8)
{P("Incompatible with your sys\n"); R 0;}
// P("c=%d s=[%s]\n", c, (a[0]==0?"NULL": a[0]) );
if(c<=1) {P("Uso: \">program.exe nomeFile\" \n"); R 0;}
pf=fopen(a[1], "rb");
if(pf==0){P("ERRORE: Non riesco a aprire il file\n"); R 0;}
F(i=0; i<256; ++i)
nc[i]=0;
W(1){i=fgetc(pf);
if(i==(u32)-1||i>=256)
break;
++nc[i];
}
if((i!=(u32)-1&&i>=256)||ferror(pf))
{fclose(pf);
err: P("Some error in read the file\n"); R 0;}
fclose(pf);
F(i=0, cont=0; i<256; ++i)
{cont+=nc[i];
if(cont>=0xFFFFFF) G err;
}
F(i=0; i<256; ++i)
{if(i=='\t')
P("[\\t, %u]", nc[i]);
else if(i=='\a')
P("[\\a, %u]", nc[i]);
else if(i=='\r')
P("[\\r, %u]", nc[i]);
else if(i=='\n')
P("[\\n, %u]", nc[i]);
else if(i=='\b')
P("[\\b, %u]", nc[i]);
else if(i=='\f')
P("[\\f, %u]", nc[i]);
else if(i=='\v')
P("[\\v, %u]", nc[i]);
else if(i=='\\')
P("[\\, %u]", nc[i]);
else P("[%c, %u]", i, nc[i]);
if((i+1)%10==0) P("\n");
}
P("\nN. Bytes File %s=%u\n",
(a[0]==0?"NULL": a[0]) , cont);
R 0;
lovecreatesbeauty
> {if(i=='\t')
> P("[\\t, %u]", nc[i]);
> else if(i=='\a')
> P("[\\a, %u]", nc[i]);
> else if(i=='\r')
> P("[\\r, %u]", nc[i]);
> else if(i=='\n')
> P("[\\n, %u]", nc[i]);
> else if(i=='\b')
> P("[\\b, %u]", nc[i]);
> else if(i=='\f')
> P("[\\f, %u]", nc[i]);
> else if(i=='\v')
> P("[\\v, %u]", nc[i]);
> else if(i=='\\')
> P("[\\, %u]", nc[i]);
> else P("[%c, %u]", i, nc[i]);
i think there're some other chars can't be printed. see the demo of
your code. Note the last "PuTTY" brought by running your code.
$ make && ./a.out ./intro.wmv
[cut]
N. Bytes File ./a.out=665107
$ PuTTY
io_x
"lovecreatesbeauty" <lovecrea...@gmail.com> ha scritto nel messaggio
news:203fd31e-5f12-4919...@h12g2000pro.googlegroups.com...
i hope it not changed something on your tty...
what about this?
-------------
#include <stdio.h>
#include <stdint.h>
#include <limits.h>
#include <ctype.h>
// macro for types
#define u64 uint64_t
#define u32 uint32_t
#define u16 uint16_t
#define u8 uint8_t
// macro for function
#define P printf
// macro for keyWords
#define G goto
#define R return
#define W while
#define F for
int main(int c, char** a)
{u32 nc[256], i, cont, r;
FILE *pf;
if(sizeof(u32)!=sizeof(int)||CHAR_BIT!=8)
{P("Incompatible with your sys\n"); R 0;}
// P("c=%d s=[%s]\n", c, (a[0]==0?"NULL": a[0]));
if(c<=1) {P("Uso: \">program.exe nomeFile\" \n"); R 0;}
pf=fopen(a[1], "rb");
if(pf==0){P("ERRORE: Non riesco a aprire il file\n"); R 0;}
F(i=0; i<256; ++i)
nc[i]=0;
W(1){i=fgetc(pf);
if(i==(u32)-1||i>=256)
break;
++nc[i];
}
if((i!=(u32)-1&&i>=256)||ferror(pf))
{fclose(pf);
err: P("Some error in read the file\n"); R 0;}
fclose(pf);
F(i=0, cont=0; i<256; ++i)
{r=cont;
cont+=nc[i];
if(cont<r) G err;
}
F(i=0; i<256; ++i)
{if(i=='\t')
P("[%3u,\\t, %5u]",i, nc[i]);
else if(i=='\a')
P("[%3u,\\a, %5u]", i, nc[i]);
else if(i=='\r')
P("[%3u,\\r, %5u]", i, nc[i]);
else if(i=='\n')
P("[%3u,\\n, %5u]", i, nc[i]);
else if(i=='\b')
P("[%3u,\\b, %5u]", i, nc[i]);
else if(i=='\f')
P("[%3u,\\f, %5u]", i, nc[i]);
else if(i=='\v')
P("[%3u,\\v, %5u]", i, nc[i]);
else if(i=='\\')
P("[%3u, \\, %5u]", i, nc[i]);
else if(!isprint(i))
P("[%3u, ?, %5u]", i, nc[i]);
else P("[%3u, %c, %5u]", i, i, nc[i]);
if((i+1)%5==0) P("\n");
}
P("\nN. Bytes File %s=%u\n", (a[1]==0?" ": a[1]), cont);
R 0;
}
-------------
[ 0, ?, 1248][ 1, ?, 1333][ 2, ?, 1429][ 3, ?, 1369][ 4, ?, 1276]
[ 5, ?, 1343][ 6, ?, 1413][ 7,\a, 1405][ 8,\b, 1367][ 9,\t, 1290]
[ 10,\n, 30524][ 11,\v, 1391][ 12,\f, 1313][ 13,\r, 1332][ 14, ?, 1444]
[ 15, ?, 1466][ 16, ?, 1435][ 17, ?, 1348][ 18, ?, 1405][ 19, ?, 1344]
[ 20, ?, 1424][ 21, ?, 1255][ 22, ?, 1473][ 23, ?, 1394][ 24, ?, 1435]
[ 25, ?, 1291][ 26, ?, 1424][ 27, ?, 1312][ 28, ?, 1448][ 29, ?, 1277]
[ 30, ?, 1417][ 31, ?, 1333][ 32, , 58554][ 33, !, 1253][ 34, ", 1279]
[ 35, #, 1298][ 36, $, 1403][ 37, %, 1371][ 38, &, 1350][ 39, ', 1290]
[ 40, (, 2050][ 41, ), 1851][ 42, *, 1316][ 43, +, 1326][ 44, ,, 1619]
[ 45, -, 3583][ 46, ., 15008][ 47, /, 27925][ 48, 0, 60635][ 49, 1, 17627]
[ 50, 2, 17869][ 51, 3, 14044][ 52, 4, 16861][ 53, 5, 16944][ 54, 6, 11511]
[ 55, 7, 10704][ 56, 8, 11907][ 57, 9, 10207][ 58, :, 1763][ 59, ;, 1418]
[ 60, <, 8730][ 61, =, 1349][ 62, >, 8598][ 63, ?, 1313][ 64, @, 1343]
[ 65, A, 3910][ 66, B, 5000][ 67, C, 1925][ 68, D, 4814][ 69, E, 1634]
[ 70, F, 2642][ 71, G, 1399][ 72, H, 1363][ 73, I, 1726][ 74, J, 1397]
[ 75, K, 1293][ 76, L, 3943][ 77, M, 1906][ 78, N, 2002][ 79, O, 1534]
[ 80, P, 3911][ 81, Q, 1513][ 82, R, 11581][ 83, S, 4410][ 84, T, 4797]
[ 85, U, 1573][ 86, V, 1529][ 87, W, 1499][ 88, X, 2159][ 89, Y, 2299]
[ 90, Z, 2124][ 91, [, 7089][ 92, \, 1330][ 93, ], 7118][ 94, ^, 1364]
[ 95, _, 1283][ 96, `, 1366][ 97, a, 4532][ 98, b, 10837][ 99, c, 6712]
[100, d, 8329][101, e, 26005][102, f, 1544][103, g, 2151][104, h, 1766]
[105, i, 7824][106, j, 8641][107, k, 3631][108, l, 4565][109, m, 2140]
[110, n, 21112][111, o, 17556][112, p, 6279][113, q, 1413][114, r, 9049]
[115, s, 7995][116, t, 18286][117, u, 4923][118, v, 2021][119, w, 1432]
[120, x, 2629][121, y, 6059][122, z, 1356][123, {, 1455][124, |, 1331]
[125, }, 1492][126, ~, 1253][127, ?, 1166][128, ?, 1312][129, ?, 1304]
[130, ?, 1345][131, ?, 1358][132, ?, 1309][133, ?, 1245][134, ?, 1331]
[135, ?, 1445][136, ?, 1371][137, ?, 1318][138, ?, 1333][139, ?, 1387]
[140, ?, 1302][141, ?, 1348][142, ?, 1305][143, ?, 1374][144, ?, 1320]
[145, ?, 1304][146, ?, 1350][147, ?, 1359][148, ?, 1466][149, ?, 1320]
[150, ?, 1403][151, ?, 1274][152, ?, 1363][153, ?, 1383][154, ?, 1375]
[155, ?, 1335][156, ?, 1597][157, ?, 1274][158, ?, 1480][159, ?, 1295]
[160, ?, 1286][161, ?, 1366][162, ?, 1375][163, ?, 1415][164, ?, 1274]
[165, ?, 1252][166, ?, 1369][167, ?, 1315][168, ?, 1343][169, ?, 1333]
[170, ?, 1467][171, ?, 1492][172, ?, 1325][173, ?, 1352][174, ?, 1423]
[175, ?, 1363][176, ?, 1285][177, ?, 1379][178, ?, 1525][179, ?, 1369]
[180, ?, 1255][181, ?, 1385][182, ?, 1481][183, ?, 1333][184, ?, 1265]
[185, ?, 1301][186, ?, 1443][187, ?, 1412][188, ?, 1254][189, ?, 1359]
[190, ?, 1405][191, ?, 1284][192, ?, 1412][193, ?, 1313][194, ?, 1273]
[195, ?, 1424][196, ?, 1284][197, ?, 1364][198, ?, 1239][199, ?, 1478]
[200, ?, 1429][201, ?, 1299][202, ?, 1339][203, ?, 1438][204, ?, 1385]
[205, ?, 1297][206, ?, 1346][207, ?, 1422][208, ?, 1340][209, ?, 1320]
[210, ?, 1299][211, ?, 1397][212, ?, 1349][213, ?, 1435][214, ?, 1243]
[215, ?, 1485][216, ?, 1369][217, ?, 1395][218, ?, 1291][219, ?, 1717]
[220, ?, 1261][221, ?, 1430][222, ?, 1261][223, ?, 1450][224, ?, 1427]
[225, ?, 1307][226, ?, 1285][227, ?, 1458][228, ?, 1310][229, ?, 1330]
[230, ?, 1337][231, ?, 1395][232, ?, 1378][233, ?, 1279][234, ?, 1443]
[235, ?, 1357][236, ?, 1374][237, ?, 1461][238, ?, 1373][239, ?, 1381]
[240, ?, 1357][241, ?, 1309][242, ?, 1346][243, ?, 1401][244, ?, 1354]
[245, ?, 1381][246, ?, 1409][247, ?, 1395][248, ?, 1244][249, ?, 1309]
[250, ?, 1304][251, ?, 1375][252, ?, 1226][253, ?, 1314][254, ?, 1184]
[255, ?, 1193]
N. Bytes File nasmdoc.pdf=870724
--------------------------------
Seebs
> Thank you, Seebs!
It's utterly surreal.
I'm so happy to have been promoted to "eurotrash".
io_x
"io_x" <a...@b.c.invalid> ha scritto nel messaggio
news:4df794e8$0$45734$4faf...@reader2.news.tin.it...
in the count of each char i forgot to see for nc[]s overflow
W(1){i=fgetc(pf);
if(i==(u32)-1||i>=256)
break;
++nc[i];
if(nc[i]==0) G err1;
}
> if((i!=(u32)-1&&i>=256)||ferror(pf))
{err1: fclose(pf);
Ian Collins
>
> this is my try, i know there will be error etc etc
> i'm not perfect...
>
> #include<stdio.h>
> #include<stdint.h>
> #include<limits.h>
>
> // macro for types
> #define u64 uint64_t
> #define u32 uint32_t
> #define u16 uint16_t
> #define u8 uint8_t
>
> // macro for function
> #define P printf
Readers can stop here!
--
Ian Collins
Joe Pfeiffer
> // macro for types
> #define u64 uint64_t
> #define u32 uint32_t
> #define u16 uint16_t
> #define u8 uint8_t
>
> // macro for function
> #define P printf
>
> // macro for keyWords
> #define G goto
> #define R return
> #define W while
> #define F for
Please, no.
Michael Press
wrote:
[...]
Code as disorganized as what you present here will fail
with high probability. You have posted in clc enough to
have heard most of the advice on writing good code, and
heard all the mistakes tyros make, some of which you
made here.
Perhaps at this time you are incapable of writing good
beginner's code even with help. What do you say? Do you
want to tackle this?
--
Michael Press
Oliver Jackson
> On 06/12/2011 03:42 PM, Eric Sosman wrote:
>
> > On 6/12/2011 4:47 PM, Uno wrote:
>
> >> and I needed to start to somehwhere.
>
> > 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.
>
> It takes me a few posts before I get a syntactical C program to use to
> describe what I'm doing. Without referent source, I can't communicate this.
>
>
>
> >> compiles, I like to have the magic numbers #defined.
>
> > 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.
>
> But you did notice that I have
> #define SIZE2 (UCHAR_MAX+1)
> , and this was the seg fault I couldn't get my head around when I first
> posted.
Yes, but that's just because you're a paste eating, curry sniffing,
crap gargling, strychnine snorting, methane huffing, egg suckin',
famcon attending, plushie humping, brassiere wearing, bumper sticker
displaying, nym shifting, gui loving, garbage eating, mouth breathing,
card carrying dumbass.
Uno
> On 2011-06-14, Keith Thompson<ks...@mib.org> wrote:
>> Thank you, Seebs!
>
> It's utterly surreal.
>
> I'm so happy to have been promoted to "eurotrash".
>
> -s
Don't flatter yourself. Keith seems to keep a loser as a wingman.
--
Uno
Uno
Get bent. That's english for your english sucks.
And plonk.
--
Uno
Michael Press
wrote:
What does English have to do with this?
> And plonk.
That's not English.
--
Michael Press
James Waldby
> In article <95tq70...@mid.individual.net>, Uno <U...@example.invalid>
> wrote:
>> On 06/15/2011 02:06 PM, Michael Press wrote:
...
>> > Code as disorganized as what you present here will fail with high
>> > probability. You have posted in clc enough to have heard most of the
>> > advice on writing good code, and heard all the mistakes tyros make,
>> > some of which you made here.
>> >
>> > Perhaps at this time you are incapable of writing good beginner's
>> > code even with help. What do you say? Do you want to tackle this?
>> >
>> Get bent. That's english for your english sucks.
>
> What does English have to do with this?
>
>> And plonk.
>
> That's not English.
It certainly is. For example, the Wikipedia entry for Plonk (wine)
says "Plonk is an unspecific and derogatory term in British and
Australian English for wine that is notably inexpensive or judged
to be of poor quality." However, Uno, who is the plonker[*] in
the above exchange, undoubtedly meant it in the Plonk (Usenet)
sense, "adding a particular Usenet poster to one's kill file".
[*] <http://en.wikipedia.org/wiki/Plonker>
--
jiw
J. J. Farrell
Interesting; not that it's topical, but what's wrong with his English?
It looks fine to me.
Tim Rentsch
> 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.