input word

[arnuld]

We have discussed this program a lot. Only two problems have remained with
this code:

/* a function written in ANSI C, that takes a word from stdin and manages the memory dynamically
*
* Since there is no generally agreed definition of what a 'word' is. I have taken a very simple
* approach:
*
* A word is a contiguous collection of non-whitespace characters. A whitespace means anyone of
* a single apace, a newline or a tab.
*
*
*/
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
enum { WORD_SIZE = 28 };
enum { GSW_OK, GSW_ENOMEM, GSW_ENORESIZE } ;
int get_single_word( char** );

int main( void )
{
char* pword;
while( (GSW_OK == get_single_word(&pword)) && ( *pword != 0) )
{
printf("You entered: [%s]\n", pword);
free( pword );
}
return 0;
}


int get_single_word( char** ppc )
{
unsigned ele_num = 0;
int ch;
size_t word_length = WORD_SIZE;
size_t word_length_interval = 2;

char* word_begin;
char* new_mem;

*ppc = malloc(word_length * sizeof(**ppc));
word_begin = *ppc;
if( NULL == ppc )
{
return GSW_ENOMEM;

}
while( (EOF != (ch = getchar())) && isspace(ch) )
{
continue; /* Leading whitespace */
}
if( EOF != ch )
{
*word_begin++ = ch;
ele_num = 1;
}
while( (EOF != (ch = getchar())) && (! isspace(ch)) )
{
if( (word_length - 1) == ele_num++ )
{
new_mem = realloc( *ppc, (word_length_interval * word_length * sizeof *new_mem) );

if( new_mem )
{
word_begin = new_mem + (word_begin - *ppc);
word_length *= word_length_interval;
*ppc = new_mem;
}
else
{
*word_begin = '\0';
return GSW_ENORESIZE;
}
}

*word_begin++ = ch;
}
*word_begin = '\0';

return GSW_OK;
}

1) the get_single_word program is 60 lines long when there is
general agreement that no function should be longer than 40
lines.

2) distinguishing between real EOF and the error.


For (1) all I can think of is to take while() loop (from
get_single_word) out into a new function which will require passing 6
variables as pointer (or pointer to pointer) arguments: new_mem,
word_begin, word_length, word_length_interval, ppc and ele_num. I think
that will be messy solution.
Regarding (2) I have to use feof() and ferror() which are little
confusing.

--
www.lispmachine.wordpress.com
my email is @ the above blog.
Gooogle Groups is Blocked. Reason: Excessive Spamming

[Tim Rentsch]

James Kuyper <ja*********@verizon.netwrites:

arnuld wrote:
...

1) Reduce statements to their most compact form
For example, the 5 line
if ( NULL == ppc )
{
return GSW_ENOMEM;
would become the one line
if (NULL == ppc ) return GSW_ENOMEM;
eliminating four lines,

I will like to see what other clc posters has to say about this say. If
they agree, I will drop this kind into my style-bucket. Personally, I
liked it :)

The compact form presents problems due to the fact that the if condition
and the return statement are on the same line. [...]

I think 'tradeoffs' is a more appropriate word than 'problems'.
The one-line form also has its own advantages (without trying to
decide which set of advantages might outweigh the other).

Furthermore, if the one-line form is used, it's a simple matter
to produce source automatically that uses the two-line form,
which makes (most of) both sets of advantages available.

[Tim Rentsch]

William Pursell <bi**********@gmail.comwrites:

On 6 Oct, 22:02, Ben Pfaff <[e-mail]:

arnuld <[e-mail]:

>On Fri, 03 Oct 2008 10:37:29 -0700, Lew Pitcher wrote:
>1) Reduce statements to their most compact form
>=A0 =A0For example, the 5 line
>=A0 =A0 =A0 if ( NULL =3D=3D ppc )
>=A0 =A0 =A0 =A0 =A0{
>=A0 =A0 =A0 =A0 =A0 =A0return GSW_ENOMEM;

>=A0 =A0would become the one line
>=A0 =A0 =A0 if (NULL =3D=3D ppc ) return GSW_ENOMEM;
>=A0 =A0eliminating four lines,

I will like to see what other clc posters has to say about this say. If
they agree, I will drop this kind into my style-bucket. Personally, I
liked it :)

I always put a line break between an "if" statement and any
statement conditional upon it. =A0I find it easier to read.

Also, having the statement on a separate line makes code
coverage tests more useful. For example, gcov has line based
granularity and can tell you how often each line has been
executed in your test suite. If the statement and
the condition appear on the same line, then it
generates less accurate reports.

Not less accurate; just sometimes having less information.

To give one example, information for how often each line has been
executed for this code sequence

if(x)
return 0;
...

won't have any more information than the same analysis for this
code sequence

if(x) return 0;
...

[jameskuyper]

Tim Rentsch wrote:
....

Not less accurate; just sometimes having less information.

To give one example, information for how often each line has been
executed for this code sequence

if(x)
return 0;
...

won't have any more information than the same analysis for this
code sequence

if(x) return 0;
...

I think you meant "accuracy" rather "information" in your last
sentence. As written, it makes no sense; there's quite clearly half as
much information in the second case as in the first.

[Ben Bacarisse]

ja*********@verizon.net writes:

Tim Rentsch wrote:
...

>Not less accurate; just sometimes having less information.

To give one example, information for how often each line has been
executed for this code sequence

if(x)
return 0;
...

won't have any more information than the same analysis for this
code sequence

if(x) return 0;
...

I think you meant "accuracy" rather "information" in your last
sentence. As written, it makes no sense; there's quite clearly half as
much information in the second case as in the first.

I, too, was confused but then I though that what was being illustrated
was the "sometimes". I.e. the text round the example is correct and
the example is to show that one may, sometimes, not _even_ loose
information (much less accuracy).

A coverage tool that reports

<a timesif (x)
<b times return 0;
<c times...

gives exactly the same information as one that reports

<a timesif (x) return 0;
<c times...

since b = a - c.

Of course, if the tools don't work that way then this is wrong, but it
fits what was written.

--
Ben.

[Tim Rentsch]

ja*********@verizon.net writes:

Tim Rentsch wrote:
...

Not less accurate; just sometimes having less information.

To give one example, information for how often each line has been
executed for this code sequence

if(x)
return 0;
...

won't have any more information than the same analysis for this
code sequence

if(x) return 0;
...

I think you meant "accuracy" rather "information" in your last
sentence. As written, it makes no sense; there's quite clearly half as
much information in the second case as in the first.

I meant "information" in the sense of information theory. The
three per-line execution counts for the lines

if(x)
return 0;
...

have more /data/ than the two counts for the lines

if(x) return 0;
...

but they don't contain more information.

[Tim Rentsch]

Ben Bacarisse <be********@bsb.me.ukwrites:

ja*********@verizon.net writes:

Tim Rentsch wrote:
...

Not less accurate; just sometimes having less information.

To give one example, information for how often each line has been
executed for this code sequence

if(x)
return 0;
...

won't have any more information than the same analysis for this
code sequence

if(x) return 0;
...

I think you meant "accuracy" rather "information" in your last
sentence. As written, it makes no sense; there's quite clearly half as
much information in the second case as in the first.

I, too, was confused but then I though that what was being illustrated
was the "sometimes". I.e. the text round the example is correct and
the example is to show that one may, sometimes, not _even_ loose
information (much less accuracy).

A coverage tool that reports

<a timesif (x)
<b times return 0;
<c times...

gives exactly the same information as one that reports

<a timesif (x) return 0;
<c times...

since b = a - c.

Of course, if the tools don't work that way then this is wrong, but it
fits what was written.

Yes, exactly my point.

Furthermore, this example is significant, because control
transfers (including break, continue, and yes even goto) usually
seem better placed (IMO) on the same level/line as the 'if',
rather than indented underneath it. All control transfers
have this information-preserving property with respect to
line execution counts.

[David Thompson]

On Fri, 03 Oct 2008 17:31:23 -0700, Barry Schwarz <sc******@dqel.com>
wrote:

On Fri, 03 Oct 2008 11:24:02 +0500, arnuld <su*****@invalid.address>
wrote:

[for OP's program:]

* A word is a contiguous collection of non-whitespace characters. A whitespace means anyone of
* a single apace, a newline or a tab.

You use isspace to detect whitespace. isspace will return true for
several other characters besides these three.

Though at least in the (default) C locale, all of them are characters
that if used (which they are not so much nowadays except where \r
leaks through) any sane person would treat unconditionally as nonword,
so the OP should just extend their spec to agree with isspace().

(The harder part to word delimiting, as previously discussed at
length, are things like apostrophe esp if also used for singlequote
and/or acute, other confusable quasi-accents, hyphen, period/stop,
etc., which the OP has explicitly decided not to deal with.)

<snip>

Regarding (2) I have to use feof() and ferror() which are little
confusing.

They are mutually exclusive in this case so you only need to use one
or the other. If the one you use returns 1, then that condition is
true. (E.g., if you use feof and it returns 1, then you reached end
of file and don't have an error). If the one you use returns 0, then
the other condition is true.

Supernit: s/1/nonzero/
The builtin operators (== != < <= = && || !) yield one or zero, but
the library routines (e.g. feof and is[w]*) return nonzero or zero.

- formerly david.thompson1 || achar(64) || worldnet.att.net

[David Thompson]

On Sat, 04 Oct 2008 08:32:23 +1300, Ian Collins <ia******@hotmail.com>
wrote:

arnuld wrote:

On Fri, 03 Oct 2008 23:22:03 +1300, Ian Collins wrote:

Which do you prefer, stumbling around in the dark, or turning on the light?

Using debugger means shutting down your brain. Thats what I think because
If I can't understand what I wrote in just 24 lines, I better throw the
code and start again.

That's a false choice. Certainly you should not shut down your brain,
and if you don't understand your code starting over is usually good.
But it is entirely possible to use a debugger with your brain on.

Then test as you go. Write a simple test, write the code to pass it,
check in. Repeat until done.

Yes. (But make sure the tests are correct. Sometimes, like bad specs,
it's easy to get both wrong in compatible ways; that doesn't help.)

Then if you add come code that breaks, just revert the change and do it
again.

But no. _Look_ at the change(s) first to try to figure out the
problem. 99% of the time you will find it, with much less effort than
investigating or analyzing the whole program. And that's a win.

But don't assume that the problem _must_ be in the last change, or
even last few. Sometimes a code change -- or a test change -- will
expose a latent bug that was already there, in code that didn't
change, sometimes code that has been there for years. We tell
ourselves, and each other, "oh, that code has been extensively tested
and widely used, it can't be wrong" but for (sub)programs of any
significant complexity and/or context the number of possible execution
histories is usually so huge that no testing could ever be exhaustive.
- formerly david.thompson1 || achar(64) || worldnet.att.net