On Thu, 18 Sep 2008 22:46:07 +0500, arnuld wrote:

> You are wrong. Most Indian students say that you need Windows to run a
> computer, without Windows you can not use a computer. I have yet to meet
> a person who uses Linux as his daily use OS.
>>

Off topic, but what the hell. I, living in Southern California, have yet
to meet anybody who uses linux. Besides myself, and people I have given
computers to. I work in construction, and have been in many offices, and
have seen nothing but window and mac boxes. Eventually, if my children
let me have some free time, I will join a LUG.

sf

> On Fri, 19 Sep 2008 05:20:08 +0000, jellybean stonerfish wrote:

> Off topic, but what the hell. I, living in Southern California, have yet
> to meet anybody who uses linux. Besides myself, and people I have given
> computers to. I work in construction, and have been in many offices, and
> have seen nothing but window and mac boxes. Eventually, if my children
> let me have some free time, I will join a LUG.

Thats what *exactly* I am telling. Indian students and users are same as
American students or users. People wrongly believe that Indian guys are
much more computer literate. Like US or Germany, most don't even
understand the difference between OS and Windows.

On Fri, 19 Sep 2008 10:35:57 +0500, arnuld wrote:

>> On Fri, 19 Sep 2008 05:20:08 +0000, jellybean stonerfish wrote:
>
>> Off topic, but what the hell. I, living in Southern California, have
>> yet to meet anybody who uses linux. Besides myself, and people I have
>> given computers to. I work in construction, and have been in many
>> offices, and have seen nothing but window and mac boxes. Eventually,
>> if my children let me have some free time, I will join a LUG.
>
> Thats what *exactly* I am telling. Indian students and users are same as
> American students or users. People wrongly believe that Indian guys are
> much more computer literate. Like US or Germany, most don't even
> understand the difference between OS and Windows.

In other words, stupidity has no boundaries.

sf

arnuld wrote, On 19/09/08 06:35:
>> On Fri, 19 Sep 2008 05:20:08 +0000, jellybean stonerfish wrote:
>
>> Off topic, but what the hell. I, living in Southern California, have yet
>> to meet anybody who uses linux. Besides myself, and people I have given
>> computers to. I work in construction, and have been in many offices, and
>> have seen nothing but window and mac boxes. Eventually, if my children
>> let me have some free time, I will join a LUG.
>
> Thats what *exactly* I am telling. Indian students and users are same as
> American students or users.

It varies in India, America and the US. There are definitely people in
Silicon Valley who know about and use Linux. The majority of people
outside IT don't know and don't care.

> People wrongly believe that Indian guys are
> much more computer literate.

I have talked to other people involved in SW outsourcing to India and
I've yet to meet people who believe that. Don't get me wrong, I'm not
saying Indian people are less intelligent, just that the people I've met
involved in doing outsourcing SW to India do it because the staff are
cheap enough that you can hire enough to make up for the staff being
*less* able. This is one reason why certain key parts of the SW
development are kept in the UK/USA/wherever.

> Like US or Germany, most don't even
> understand the difference between OS and Windows.

For most people the computer should just be an appliance. They want to
do word processing, play games, browse the web etc. It is US who should
be making it possible to do that *without* knowing or caring about the
OS. Of course, the OS needs to be locked down for people like that so
that they can't break it (cue OS wars). People in IT and SW development
are and should be different.

> On Thu, 18 Sep 2008 13:25:51 +0000, Richard Heathfield wrote:

> ...SNIP...

> What you meant to write is:
>
> *pw_begin++ = pword;
>
> This is legal because * has higher precedence than = so what happens is
> that ++ yields the old value of pw_begin, * gives us the object to which
> that old value points, and = now assigns to the object. Since pw_begin has
> type char **, pw_begin++ has type char **, *pw_begin++ has type char * and
> is a real object, so we can assign a char * value to it. pword is one such
> value.


I understood completely the *pw_begin++ part, the confusion remains in
in the Right Hand Side, the pword has triple levels of indirection ***.
while pw_begin has two **. So dereferencing pw_begin gives me single level
of indirection. SO it looks like this:

* = ***


thats what confusing me an din that confusion I did &pword :(

arnuld said:

<snip>

> I understood completely the *pw_begin++ part, the confusion remains in
> in the Right Hand Side, the pword has triple levels of indirection ***.

No, it doesn't. Read the code again: pword is of type char *.

CBFalconer <cbfalconer> wrote:

> Richard Bos wrote:
> > There is also the catch that strtok() scribbles over its
> > parameter, meaning that you cannot use it to tokenise either a
> > string literal, or data you want to keep. This is something that
> > catches out a lot of less well-informed newbies.
>
> Try this:

No thanks; I've already written my own, several times for several
different situations, and I don't think a single solution would do.
Besides, it's such a simple thing to write a basic version of, with such
opportunity for a variety of approaches, that I believe this is one of
those problems which it does a newbie good to attempt his own instead of
using someone else's almost-perfect-enough solution.

Richard

> On Fri, 19 Sep 2008 08:55:41 +0000, Richard Heathfield wrote:

>> arnuld said:
>> I understood completely the *pw_begin++ part, the confusion remains in
>> in the Right Hand Side, the pword has triple levels of indirection ***.

> No, it doesn't. Read the code again: pword is of type char *.

Eh.. I think I am overwhelmed by the power pointers and arrays provide, as
with great power comes great responsibility, like Spiderman said. Anyway,
I have created little edited version of get_single_word and I wrote it
fully without taking a single look at the clc posted solutions. I am
posting it here as now it contains my own style of programming. See if you
notice something god or bad. This is final version and after that we will
start discussing get_words() and next:


/* A program that takes a single word from input
* it uses a while loop and dynamic memory allocation to take
* continuous input form user
*
*/


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


return 0;
}




int get_single_word( char** ppc )
{
unsigned idx;
int ch;
size_t arr_size;
char* pw_begin;
char* new_mem;

arr_size = WORD_SIZE;


*ppc = malloc(arr_size * sizeof(**ppc));
pw_begin = *ppc;


if( NULL == ppc )
{
return GSW_ENOMEM;

}


while( (EOF != (ch = getchar())) && isspace(ch) )
{
continue; /* trailing whitespace */
}


if( EOF != ch )
{
*pw_begin++ = ch;
}


for( idx = 0; (EOF != (ch = getchar())) && (! isspace(ch)); ++idx )
{
if( WORD_SIZE == idx )
{
new_mem = realloc( *ppc, (2 * WORD_SIZE * sizeof **ppc) );
*ppc = new_mem;

if( NULL == new_mem )
{
return GSW_ENORESIZE;
}
}

*pw_begin++ = ch;
}


*pw_begin = '\0';

return GSW_OK;
}

Nick Keighley <nick_keighley_nospam> wrote:

> On 17 Sep, 07:59, arnuld <sunr...@invalid.address> wrote:
> > ..aye.... , so lets learn the practical aspects like error-recovery too. I
> > don't like academic solutions BTW
>
> when, exactly, did "academic" become a pejorative term?

When testing became a more reliable approach to checking for bugs than
program proofs.

> "Yes it works in practice - but does it work in theory?"
>
> "There is nothing as practical as a good theory."

"Beware of the above code; I haven't tested it, but only proved it
correct."

Mind you, there _is_ a bit of difference between "academic" and "looking
this up in a beginners' textbook should show the way forward".

Richard

arnuld said:

>> On Fri, 19 Sep 2008 08:55:41 +0000, Richard Heathfield wrote:
>
>>> arnuld said:
>>> I understood completely the *pw_begin++ part, the confusion remains in
>>> in the Right Hand Side, the pword has triple levels of indirection ***.
>
>> No, it doesn't. Read the code again: pword is of type char *.
>
> Eh.. I think I am overwhelmed by the power pointers and arrays provide,
> as with great power comes great responsibility, like Spiderman said.
> Anyway, I have created little edited version of get_single_word and I
> wrote it fully without taking a single look at the clc posted solutions.
> I am posting it here as now it contains my own style of programming. See
> if you notice something god or bad.

I had a quick look through, and noticed one thing: in the event of a
realloc failure, you return an error code which indicates that the parsing
was incomplete because the memory block could not be re-sized. That's
fine, but it would be pleasant if the caller were able to attempt to
recover, and you can help with this goal by null-terminating the string
before returning (which means that you need to choose to resize just
*before* you run out of memory, as you'll need one place for the
terminator).

Apart from that, my quick glance didn't reveal anything particularly
untoward.

arnuld <sunrise> writes:
<snip>
> This is final version and after that we will
> start discussing get_words() and next:
<snip>
[..]
> {
> *pw_begin++ = ch;
> }
>> for( idx = 0; (EOF != (ch = getchar())) && (! isspace(ch)); ++idx )
> {
> if( WORD_SIZE == idx )
> {
> new_mem = realloc( *ppc, (2 * WORD_SIZE * sizeof **ppc) );

This looks very odd. You realloc once when idx == WORD_SIZE but if
2 * WORD_SIZE is not enough, then what?

> *ppc = new_mem;
>
> if( NULL == new_mem )
> {
> return GSW_ENORESIZE;
> }

You have both a memory leak and logic error here. As I pointed out
before, when you allocate new memory you must make pw_begin point to
the right place. You've change the code, but not made it correct
yet. If the realloc is OK, you need pw_begin to point (about) idx
places into new_mem.

The leak is caused only when realloc fails. You set *ppc to NULL (the
return from realloc) but that loses the pointer to the word so it can
now ever be freed.

> }
>
> *pw_begin++ = ch;

You need also to check all your index counts. This will write the at
index 3 into a string of length 3 (i.e. out of bounds) and the text
for reallocation is wrong as well. You need to realloc space when idx
== WORD_SIZE - 2 (I think) since idx in incremented late and you must
have space for the null. Anyway, check them (and use valgrind).
[..]

Ben Bacarisse said:

> arnuld <sunrise> writes:
<snip>
>>
>> for( idx = 0; (EOF != (ch = getchar())) && (! isspace(ch)); ++idx )
>> {
>> if( WORD_SIZE == idx )
>> {
>> new_mem = realloc( *ppc, (2 * WORD_SIZE * sizeof **ppc) );
>
> This looks very odd. You realloc once when idx == WORD_SIZE but if
> 2 * WORD_SIZE is not enough, then what?

Oh, good spot. I *showed* him how to do this. It didn't occur to me to
check that he had bothered to listen. Sheesh, furrfu, etc.

>> *ppc = new_mem;
>>
>> if( NULL == new_mem )
>> {
>> return GSW_ENORESIZE;
>> }
>
> You have both a memory leak and logic error here. As I pointed out
> before, when you allocate new memory you must make pw_begin point to
> the right place. You've change the code, but not made it correct
> yet. If the realloc is OK, you need pw_begin to point (about) idx
> places into new_mem.

Another good spot.

Again, I showed him how to do this properly. Perhaps he has reading
difficulties?

> On Fri, 19 Sep 2008 12:05:24 +0100, Ben Bacarisse wrote:

>> arnuld <sunrise> writes:
>> for( idx = 0; (EOF != (ch = getchar())) && (! isspace(ch)); ++idx )
>> {
>> if( WORD_SIZE == idx )
>> {
>> new_mem = realloc( *ppc, (2 * WORD_SIZE * sizeof **ppc) );

> This looks very odd. You realloc once when idx == WORD_SIZE but if
> 2 * WORD_SIZE is not enough, then what?


How about adding idx = 0; after new_mem line ?



>> *ppc = new_mem;
>>
>> if( NULL == new_mem )
>> {
>> return GSW_ENORESIZE;
>> }

> You have both a memory leak and logic error here. As I pointed out
> before, when you allocate new memory you must make pw_begin point to
> the right place. You've change the code, but not made it correct
> yet. If the realloc is OK, you need pw_begin to point (about) idx
> places into new_mem.


you pointed it out in get_words code but this function you quoted is
get_single_word. ppc is the pointer to pointer to char that you get from
function argument, which will be passed to free() in main(). pw_begin is
used to put input characters into the array. so both ppc and pw_begin need
to point to new_mem. right ?



> The leak is caused only when realloc fails. You set *ppc to NULL (the
> return from realloc) but that loses the pointer to the word so it can
> now ever be freed.

okay, I have added an else statement aligning with if clause.



>> *pw_begin++ = ch;
>
> You need also to check all your index counts. This will write the at
> index 3 into a string of length 3 (i.e. out of bounds) and the text for
> reallocation is wrong as well. You need to realloc space when idx ==
> WORD_SIZE - 2 (I think) since idx in incremented late and you must have
> space for the null. Anyway, check them (and use valgrind).

I really did not understand what you mean. I mean, i am unable to
comprehend what you said. This is my new code with buggy output:


/* A program that takes a single word from input
* it uses a while loop and dynamic memory allocation to take
* continuous input form user
*
* VERSION: 1.1
*
*/


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


enum { WORD_SIZE = 3 };
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);
}


return 0;
}




int get_single_word( char** ppc )
{
unsigned idx;
int ch;
size_t arr_size;
char* pw_begin;
char* new_mem;

arr_size = WORD_SIZE;


*ppc = malloc(arr_size * sizeof(**ppc));
pw_begin = *ppc;


if( NULL == ppc )
{
return GSW_ENOMEM;

}


while( (EOF != (ch = getchar())) && isspace(ch) )
{
continue; /* trailing whitespace */
}


if( EOF != ch )
{
*pw_begin++ = ch;
}


for( idx = 0; (EOF != (ch = getchar())) && (! isspace(ch)); ++idx )
{
if( (WORD_SIZE - 1) == idx ) /* -1 for '\0' character*/
{
new_mem = realloc( *ppc, (2 * WORD_SIZE * sizeof **ppc) );

if( NULL == new_mem )
{
*pw_begin = '\0';
return GSW_ENORESIZE;
}
else
{
pw_begin = *ppc = new_mem;
idx = 0;
}
}

*pw_begin++ = ch;
}


*pw_begin = '\0';

return GSW_OK;
}




========================= OUTPUT =======================================

[arnuld@dune ztest]$ gcc -ansi -pedantic -Wall -Wextra get-single-word.c
[arnuld@dune ztest]$ ./a.out
Richard Heathfield
You entered: [rd]
You entered: [d]
Party
You entered: [ty]
[arnuld@dune ztest]$

> On Fri, 19 Sep 2008 12:05:24 +0100, Ben Bacarisse wrote:


> You have both a memory leak and logic error here. As I pointed out
> before, when you allocate new memory you must make pw_begin point to
> the right place. You've change the code, but not made it correct
> yet. If the realloc is OK, you need pw_begin to point (about) idx
> places into new_mem.

Well, pointing pw_begin to realloc()ed memory makes whole program beahving
in a weired way, like printing only last 2 characters of an input word.
See my other reply with code and output.

On Thu, 11 Sep 2008 16:23:03 +0100, Chris Dollin <chris.dollin>
wrote:

> arnuld wrote:
>
> > I have not checked it but will be doing it later. The only one question
> > that keeps on popping up into my mind is "Why C was not designed to have
> > this feature ? ".
>
It's not clear (to me) if 'this feature' is input of unbounded-length
lines or of parsing words (defined as non-white); but either way ...

> Because C was designed for /implementing/ this feature; as a bare-bones
> systems programming language.
>
Actually it was designed primarily to implement an OS, which by its
nature has a pretty significant overlap with language support and
similar low-level utilities, although in practice it has been used for
a much wider range of tools and applications.

> > That reminds of an article "Back to Basics" by Joel
> > Spolsky where he said that we have null terminated strings in C whihc
> > are much slower than PASCAL strings
>
> I'd be interested in real evidence for this claim. Real, as in, it
> happened in these programs and couldn't be eliminated by straightforward
> fixes, rather than contrived examples or beginners gotchas.
>
Terminated strings in general are faster for some things and in some
cases and slower for others than counted. Especially in strict
sequential execution (little or no overlap, little or no caching, no
speculation) which was the common case then. If you use terminated, a
terminator of null is usually fastest, because many machines can
'compare' to zero more efficiently than any other value.

But since C was not originally envisioned/expected to be used for very
extensive text or string processing, I think the decision was more
(mostly) what was easy and fast to _implement_.

> > not by choice but by force, as C was
> > developed on PDP-7, which had ASCIZ table, which required strings to be Z
> > terminated ( Z means ZERO).
>
> That seems ... unlikely ... to me. Just because one's assembler has
> an ASCIZ directive doesn't mean one has to use it; even if one does,
> one can perfectly well also associate a length with a string as well
> as a null terminator.
>
Agree (both). Morever C wasn't developed on the -7; B was, but the
evolution into C (which occurred in several stages) began on the -11.
I'm pretty sure no DEC before VAX had standard hardware support for
either kind of string, although some -11 models did have an optional
'commercial instruction set' tailored for COBOL (or DIBOL?).

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