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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#5930

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.
>
>> 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

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

#5933

Uno <Uno@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.

-- 
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]

#5935

On 06/12/2011 05:23 PM, Keith Thompson wrote:
> Uno<Uno@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

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

#5937

On 06/13/11 11:24 AM, Uno wrote:
> On 06/12/2011 05:23 PM, Keith Thompson wrote:
>> Uno<Uno@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.

thx?

-- 
Ian Collins

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

#5941

On Mon, 13 Jun 2011 11:28:15 +1200, Ian Collins <ian-news@hotmail.com>
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". ;)

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

#5982

Uno <Uno@example.invalid> writes:
> On 06/12/2011 05:23 PM, Keith Thompson wrote:
>> Uno<Uno@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.

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.)

-- 
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]

#5978

On 2011-06-12, Keith Thompson <kst-u@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
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#6002

On 06/13/2011 08:39 AM, Seebs wrote:
> On 2011-06-12, Keith Thompson<kst-u@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

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

#6005

Uno <Uno@example.invalid> writes:
> On 06/13/2011 08:39 AM, Seebs wrote:
>> On 2011-06-12, Keith Thompson<kst-u@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.
>
> 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.

Thank you, Seebs!

-- 
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]

#6071

On 2011-06-14, Keith Thompson <kst-u@mib.org> wrote:
> Thank you, Seebs!

It's utterly surreal.

I'm so happy to have been promoted to "eurotrash".

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

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

#6138

On 06/14/2011 11:02 AM, Seebs wrote:
> On 2011-06-14, Keith Thompson<kst-u@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

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

#5967

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.

>>> 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
esosman@ieee-dot-org.invalid

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

#6003

On 06/13/2011 05:57 AM, Eric Sosman wrote:
> 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

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

#6011

On 6/13/2011 10:23 PM, Uno wrote:
> 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
esosman@ieee-dot-org.invalid

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

#6048

On Jun 14, 11:12 am, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> On 6/13/2011 10:23 PM, Uno wrote:
>
> > 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
> esos...@ieee-dot-org.invalid


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;
}
$

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

#6132

On Jun 12, 4:01 pm, Uno <U...@example.invalid> 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.
>
>
>
> >> 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.

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.

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

#5943

Uno <Uno@example.invalid> writes:

> 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.

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.

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

#5946

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;
    }

Some people prefer to do the read and EOF test in one line:
       if ((c = fgetc(fp)) == EOF) break;

-- 
jiw

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

#5948

On 06/12/2011 07:16 PM, James Waldby wrote:

> 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

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

#6053

"James Waldby" <not@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;
}


> Some people prefer to do the read and EOF test in one line:
>       if ((c = fgetc(fp)) == EOF) break;
>
> -- 
> jiw

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web