slurping in binary data

[George]

1 000100000000000 0001
2 000100000000000 0001
3 100000110010000 00000000001
4 100000110010000 00000000001
5 100000110010000 00000000001
6 100000110010000 00000000001
7 100000110010000 00000000001
8 100000110010000 00000000001
9 100000110010000 00000000001
10 100000110010000 00000000001
11 100000001111100
12 100000001111100
13 100000001111100
14 100000111011011 110000000000000 1
15 100000111011011 110000000000000 1
16 100000111011011 110000000000000 1
17 100000111011011 110000000000000 1
18 100000111011011 110000000000000 1
19 100000111011011 110000000000000 1
20 000100000000000 0001

1
2
*****
*****
*****
*****
*****
*****
*****
***** 10
************ 11
************
************
***** *** 14
***** ***
***** ***
***** ***
***** ***
***** ***
20

3W, 12 B, 5W
1000 0000111 1100

If I wanted to suck in the above 20 lines without line numbers, spaces,
carriage returns, line feeds, or anything that is not a zero, one or EOF,
how would I do it?

Thanks in advance,

--
George

Terrorist attacks can shake the foundations of our biggest buildings, but
they cannot touch the foundation of America. These acts shatter steel, but
they cannot dent the steel of American resolve.
George W. Bush

Picture of the Day http://apod.nasa.gov/apod/

[James Kuyper]

Richard Heathfield wrote:

James Kuyper said:

>George wrote:

<snip>

>>Would you prefer fgets to either Chuck's or Richard's enhancements?

My news server reports that there are currently 18 messages in this
thread. One was posted by Chuck Falconer, and 2 by Richard Heathfield,

and all three of them *after* George's message.

>none by anyone else named Chuck or Richard. All three of those messages
are short comments which don't suggest anything I would call an
enhancement. Are you referring to messages which haven't been showing up
on my news server?

Despite his use of the word "enhancemen t", George may be referring to Chuck
Falconer's ggets() function.

Ah! If so, I will say that I share your frequently expressed negative
opinion of that function, though I don't disapprove of it quite as
passionately as you do.
To George: Google for messages by Richard Heathfield containing ggets().

My biggest problem with ggets() is the lack of support for re-using
buffers that have already been allocated. On those rare occasions when I
want to do anything remotely similar to ggets(), I usually use a
single-line buffer which I realloc() to a larger size whenever a line
comes in which is too big for the current buffer size. I almost never
want to waste time allocating a brand new buffer for every single line
of the input file.

[Richard Heathfield]

James Kuyper said:

Richard Heathfield wrote:

<snip>

>Despite his use of the word "enhancemen t", George may be referring to
Chuck Falconer's ggets() function.

Ah! If so, I will say that I share your frequently expressed negative
opinion of that function, though I don't disapprove of it quite as
passionately as you do.

There's nothing wrong with it that can't be fixed. Unfortunately, the owner
doesn't seem to agree that it needs fixing.

<snip>

My biggest problem with ggets() is the lack of support for re-using
buffers that have already been allocated.

Right. It's not exactly difficult to take a char ** and a size_t *.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Nate Eldredge]

James Kuyper <ja*********@ve rizon.netwrites :

My biggest problem with ggets() is the lack of support for re-using
buffers that have already been allocated. On those rare occasions when
I want to do anything remotely similar to ggets(), I usually use a
single-line buffer which I realloc() to a larger size whenever a line
comes in which is too big for the current buffer size. I almost never
want to waste time allocating a brand new buffer for every single line
of the input file.

I'll put in a plug for something like the getline() function from glibc.

ssize_t getline (char **LINEPTR, size_t *N, FILE *STREAM);

*LINEPTR should be a pointer to a buffer of size *N obtained from
malloc. If it is not large enough, it's expanded with realloc, and
*LINEPTR and *N are updated appropriately.

It's very easy to write your own version in standard C, of course.
Unfortunately glibc's code is tightly wound in with the rest of their
stdio library, otherwise it could be swiped and used verbatim in a GPL
program.

[CBFalconer]

James Kuyper wrote:

George wrote:

.... snip ...

>

>Would you prefer fgets to either Chuck's or Richard's enhancements?

My news server reports that there are currently 18 messages in this
thread. One was posted by Chuck Falconer, and 2 by Richard Heathfield,
none by anyone else named Chuck or Richard. All three of those
messages are short comments which don't suggest anything I would call
an enhancement. Are you referring to messages which haven't been
showing up on my news server?

I suspect George is referring to my ggets.c package. This is
available in public domain source form at:

<http://cbfalconer.home .att.net/download/ggets.zip>

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[George]

On Thu, 20 Nov 2008 14:44:08 +0000, Richard Heathfield wrote:

>My biggest problem with ggets() is the lack of support for re-using
buffers that have already been allocated.

Right. It's not exactly difficult to take a char ** and a size_t *.

It's difficult enough for me, who is having quite a time disambiguating all
the terms here. Chuck does have a link to your treatment of this material,
right at the bottom of readme.txt.

pg. 263, unleashed
The gets() function takes as its sole arguments a pointer to char.
Starting at that char, it will probably fill memory with data from stdin
until anewline is encountered, at which point gets90 will probably
null-terminate the string and probably return control to its caller. If,
by some miracle, STDIN contains a newline character within the first N
characters, where N is the supplied buffer, you can take the "probably"
from that sentence--for that one call. If there isn't a newline early
enough, gets() will start to trample over memory that it shouldn't be
touching, with undefined results.
If our way to slurp in these data followed roughly the declarations in
Nick's version:

gets (char data[], FILE *in)
{
char buffer [40];
int line_num;
, you wouldn't need the file *in part, because that's stdin. Are you
saying that:

14 *10000011101101 111000000000000 011111111111111 1111111111111

would screw it up?

--
George

Leadership to me means duty, honor, country. It means character, and it
means listening from time to time.
George W. Bush

Picture of the Day http://apod.nasa.gov/apod/

[George]

On Thu, 20 Nov 2008 15:40:54 -0500, CBFalconer wrote:

James Kuyper wrote:

>George wrote:

... snip ...

>>

>>Would you prefer fgets to either Chuck's or Richard's enhancements?

My news server reports that there are currently 18 messages in this
thread. One was posted by Chuck Falconer, and 2 by Richard Heathfield,
none by anyone else named Chuck or Richard. All three of those
messages are short comments which don't suggest anything I would call
an enhancement. Are you referring to messages which haven't been
showing up on my news server?

I suspect George is referring to my ggets.c package. This is
available in public domain source form at:

<http://cbfalconer.home .att.net/download/ggets.zip>

#include <stdio.h>
#include <stdlib.h>
#include "ggets.h"

#define INITSIZE 112 /* power of 2 minus 16, helps malloc */
#define DELTASIZE (INITSIZE + 16)

enum {OK = 0, NOMEM};

int fggets(char* *ln, FILE *f)

! end abridged source of ggets.c

If this is to replace the use of gets, what need have you of that file
pointer? The only use of f is in getc(f).
--
George

I believe that God has planted in every heart the desire to live in
freedom.
George W. Bush

Picture of the Day http://apod.nasa.gov/apod/

[George]

On Thu, 20 Nov 2008 02:13:43 GMT, James Kuyper wrote:

George wrote:

>On Tue, 18 Nov 2008 12:26:05 GMT, James Kuyper wrote:

>>George wrote:
On Tue, 18 Nov 2008 00:59:20 -0800 (PST), Nick Keighley wrote:
...
assuming you mean the twenty lines at the beginning. Would fgets()
followed by
>
int line_num;
char data[32];
>
fscanf (line, "%d %32s", &line_num, data);
>
do the job?
Why fgets before scanf?

Key point to keep in mind here: I was thinking of sscanf(), not fscanf()
(or scanf()). The fgets()/sscanf() combo is the best way I know of to
read most text-format files.

I hadn't even disambiguated these. Am I correct that

scanf
sscanf
fscanf

are the only ones that look like another?

>

>>Because scanf() treats newline characters the same way as any other
whitespace character. This is usually not the way they should be
handled. As a result, a single incorrectly formatted line can cause all
following lines to be handled incorrectly, causing bugs that can be a
real pain to track down.

How does fgets know to stop?

It stops at the first newline or when the buffer you've provided it is
full, or at the end of the file, whichever comes first. The key point is
the "newline" - that's what makes this approach more robust when reading
line-oriented files.

ok

>

>Presumably, we want to start scanf'ing with '1'. Let me refresh you memory
of the data set. I call it george.txt to reflect my pseudonym.

1 000100000000000 0001
2 000100000000000 0001
3 100000110010000 00000000001
4 100000110010000 00000000001
5 100000110010000 00000000001
6 100000110010000 00000000001
7 100000110010000 00000000001
8 100000110010000 00000000001
9 100000110010000 00000000001
10 100000110010000 00000000001
11 100000001111100
12 100000001111100
13 100000001111100
14 100000111011011 110000000000000 1
15 100000111011011 110000000000000 1
16 100000111011011 110000000000000 1
17 100000111011011 110000000000000 1
18 100000111011011 110000000000000 1
19 100000111011011 110000000000000 1
20 000100000000000 0001

It's 20 by forty. Given that I premise that the first datum is the line
number, do I still have to fgets?

If your input file is perfectly formatted, and your program is correctly
written, there's no need. However, I think it's poor design to write
code that fails catastrophicall y when given incorrect inputs. I believe
in designing programs so they fail gracefully when given bad input. That
means that they fail without undefined behavior, and with an informative
error message, if possible. It's a lot harder to achieve that goal with
fscanf() than it is with fgets()/sscanf().

What happens if the line number is missing from, for example, line 11?
With fscanf(), it will try to interpret 100000001111100 as a decimal
integer, and store it into the line number (with undefined behavior
unless INT_MAX is larger than that value), and then put "12" into the
data buffer. fscanf() will return a value of 2, indicating a successful
read, because it has no way of noticing that anything went wrong. With
fgets()/sscanf(), you can check whether sscanf()==2; if it does not, you
immediately know there's a problem with the line.

Continuing processing despite a problem like that can be pointless, or
mandatory, or anywhere in between those two extremes, depending upon
your application. If you keep using fscanf(), it would attempt to read
100000001111100 as the line number and put "13" into the data buffer; it
will stay out of sync with the actual lines until the end of the file,
or the next incorrectly formatted line, whichever comes first.

With fgets()/sscanf(), fgets() will start cleanly at the next line, so
sscanf() can do exactly what you need it to do; the combination of those
two functions won't stay out of sync with the data, the way fscanf() would.

#include <stdio.h>
#include <stdlib.h>

#define PATH "george.txt "
#define NUMBER 100
#define BIN 1000
#define MAXFMTLEN 2000

int main(void)
{
FILE *fp;
char pattern[MAXFMTLEN];
char lnumber[NUMBER];
char lbin[BIN];
char line[MAXFMTLEN];

if ((fp = fopen(PATH, "r")) == NULL ) {
fprintf(stderr, "can't open file\n");
exit(1);
}

sprintf(pattern , "%%%ds %%%ds", BIN-1, NUMBER-1);

while ((fgets(line, MAXFMTLEN, fp)) != NULL ) {
sscanf(line, pattern , lnumber, lbin);
/*fscanf (fp, "%d %32s", &lnumber, lbin);*/
printf("%s\n", lbin);
}
Q1) Does the while control satisfy your critism above?

Q2) Why doesn't the sprintf have to *follow* the while?

whitespace crlf
whitespace crlf
1 000100000000000 0001
2 000100000000000 0001
3 100000110010000 00000000001
4 100000110010000 00000000001
--
George

If you're sick and tired of the politics of cynicism and polls and
principles, come and join this campaign.
George W. Bush

Picture of the Day http://apod.nasa.gov/apod/

[George]

On Tue, 18 Nov 2008 09:15:43 -0800, Keith Thompson wrote:

Chad <cd*****@gmail. comwrites:
[66 lines deleted]

>>But he would would fgets() followed by fscanf(), wouldn't that just
suck in one line at a time vs all 20 lines at once? Here is what I
mean. BTW, I used sscanf() and not fscanf().

[85 lines deleted]

>>

Yikes! I forgot that using internet slang is a no no here. BTW = by
the way.

I don't think BTW is a problem; it's common enough that I think almost
everyone understands it. Silly abbreviations like "u" for "you"
are frowned upon.

But you really didn't need to quote the *entire* previous article to
add a one-line comment.

Chad's fine.

#include <stdio.h>
#include <stdlib.h>

#define PATH "george.txt "
#define NUMBER 100
#define BIN 1000
#define MAXFMTLEN 2000

int main(void)
{
FILE *fp;
char pattern[MAXFMTLEN];
char lnumber[NUMBER];
char lbin[BIN];
char line[MAXFMTLEN];

/*int line_num;
char data[32];*/
// was this an earlier version?

if ((fp = fopen(PATH, "r")) == NULL ) {
fprintf(stderr, "can't open file\n");
exit(1);
}

sprintf(pattern , "%%%ds %%%ds", BIN-1, NUMBER-1);

while ((fgets(line, MAXFMTLEN, fp)) != NULL ) {
sscanf(line, pattern , lnumber, lbin);
/*fscanf (fp, "%d %32s", &lnumber, lbin);*/
printf("%s\n", lbin);
}

fclose(fp);
return 0;
}

// gcc -o x.exe chad1.c

I see no useful distinction between

#define NUMBER 100
#define BIN 1000
, if there were to be meaningful line numbers. The next part of the
process is that I strip away anything that isn't a one or a zero in a range
of columns, so it's no big deal.

I'm a little sketchy about this line,
sscanf(line, pattern , lnumber, lbin);
in particular the meaning of pattern, when there's already a line, an
lnumber and an lbin.

BTW, everyone has equal editorial priveleges. As OP, I'm just more
equal.:-)
--
George

Saddam Hussein is a homicidal dictator who is addicted to weapons of mass
destruction.
George W. Bush

Picture of the Day http://apod.nasa.gov/apod/

[George]

On Thu, 20 Nov 2008 10:45:13 -0800, Nate Eldredge wrote:

James Kuyper <ja*********@ve rizon.netwrites :

>My biggest problem with ggets() is the lack of support for re-using
buffers that have already been allocated. On those rare occasions when
I want to do anything remotely similar to ggets(), I usually use a
single-line buffer which I realloc() to a larger size whenever a line
comes in which is too big for the current buffer size. I almost never
want to waste time allocating a brand new buffer for every single line
of the input file.

I'll put in a plug for something like the getline() function from glibc.

ssize_t getline (char **LINEPTR, size_t *N, FILE *STREAM);

*LINEPTR should be a pointer to a buffer of size *N obtained from
malloc. If it is not large enough, it's expanded with realloc, and
*LINEPTR and *N are updated appropriately.

It's very easy to write your own version in standard C, of course.
Unfortunately glibc's code is tightly wound in with the rest of their
stdio library, otherwise it could be swiped and used verbatim in a GPL
program.

Are you on gcc's mailing list? How would you do that without having 20
emails a day in a mailbox that gets 2 personal and important emails a week?

gmane?
--
George

Now, there are some who would like to rewrite history - revisionist
historians is what I like to call them.
George W. Bush

Picture of the Day http://apod.nasa.gov/apod/

[Phil Carmody]

George <ge****@example .invalidwrites:

On Thu, 20 Nov 2008 14:44:08 +0000, Richard Heathfield wrote:

>>My biggest problem with ggets() is the lack of support for re-using
buffers that have already been allocated.

Right. It's not exactly difficult to take a char ** and a size_t *.

It's difficult enough for me, who is having quite a time disambiguating all
the terms here. Chuck does have a link to your treatment of this material,
right at the bottom of readme.txt.

pg. 263, unleashed
The gets() function takes as its sole arguments a pointer to char.
Starting at that char, it will probably fill memory with data from stdin
until anewline is encountered, at which point gets90 will probably
null-terminate the string and probably return control to its caller. If,
by some miracle, STDIN contains a newline character within the first N
characters, where N is the supplied buffer, you can take the "probably"
from that sentence--for that one call. If there isn't a newline early
enough, gets() will start to trample over memory that it shouldn't be
touching, with undefined results.

Is that a 99.8% verbatim quote, because it looks horrifically mangled?
(I subtract .2%, as I presume 90 was really () sans shift key, and your
whitespace is a bit dodgy.)

Phil
--
I tried the Vista speech recognition by running the tutorial. I was
amazed, it was awesome, recognised every word I said. Then I said the
wrong word ... and it typed the right one. It was actually just
detecting a sound and printing the expected word! -- pbhj on /.