Why is that?

[Profetas]

I know what is causing the problem, but I couldn't
find out why.

#define newline "\n"
#define question_mark "\?"
#define single_quotas "\'"
#define double_quotas "\""
#define form_feed "\f"
#define horizontal_tab "\t"
#define vertical_tab "\v"
#define backslash "\\"
#include <stdio.h>

main(){
int var;
printf("Type a number:");
scanf("%d",&var);
printf("The number is ");
printf("%d",var);
printf(newline);

char *var2;
printf("Type a string:");
int bytes_read=0;
int nbytes = 100;

var2 = (char *) malloc (nbytes + 1);
bytes_read = getline (&var2, &nbytes, stdin);
if(bytes_read == -1)
{puts ("ERROR!: invalid input");}

printf("The string is ");
printf("%s",var2);
printf(newline);
}

[Michael Mair]

Hi Profetas,

I know what is causing the problem, but I couldn't
find out why.
Very enlightening. What do you think your problem is?
Your code does not even compile...
#define newline "\n"
#define question_mark "\?"
#define single_quotas "\'"
#define double_quotas "\""
#define form_feed "\f"
#define horizontal_tab "\t"
#define vertical_tab "\v"
#define backslash "\\"
Won't comment on the sense or nonsense of these macros.
Apart from the newline, you do not need that stuff. Please
keep your examples minimal.
#include <stdio.h>
Where is <stdlib.h> needed for malloc()?
And where is the header for the non-standard getline()
function? (see below, too)

main(){ int main ()
int var;
printf("Type a number:");
scanf("%d",&var);
printf("The number is ");
printf("%d",var);
printf(newline);

char *var2;
printf("Type a string:");
int bytes_read=0;
int nbytes = 100;

var2 = (char *) malloc (nbytes + 1); You have been around here long enough: Do not cast the
result of malloc(). Btw: If you want to apply a cast,
then cast nbytes -- malloc takes a size_t argument. bytes_read = getline (&var2, &nbytes, stdin); from 'man getline':
#define _GNU_SOURCE
#include <stdio.h>

ssize_t getline(char **lineptr, size_t *n, FILE *stream);
I do not know the return type ssize_t but the rest of the manpage
seems to tell me that it is an improved version of fgets() such
as most of us have in their personal library...
I would just make var2=NULL -- as getline is taking care of
allocation, this is alright for a short program.
if(bytes_read == -1) bytes_read is not of type ssize_t. {puts ("ERROR!: invalid input");} It might be another problem
printf("The string is ");
printf("%s",var2);
printf(newline);
}

free() var2. Apart from that: Why use printf() for giving
a '\n'.

Please produce code that compiles for
gcc -ansi -pedantic
and then come back.
--Michael

[Michael Mair]

Before I forget it:

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

#define newline "\n"

int main (void)
{
int var;
char *var2 = NULL;
ssize_t bytes_read = 0;
size_t nbytes = 0;
printf("Type a number: "); (void) fflush(stdout);
bytes_read = getline (&var2, &nbytes, stdin);
if(bytes_read == -1)
{
fprintf(stderr,"ERROR in line %d in return value from"
" getline()" newline, __LINE__);
(void) fflush(stderr);
exit(EXIT_FAILURE);
}
if (sscanf(var2, "%d", &var) != 1)
{
fprintf(stderr,"ERROR in line %d: scanf() could not squeeze"
" a number out of your input" newline, __LINE__);
(void) fflush(stderr);
exit(EXIT_FAILURE);
}
printf("The number is %d" newline, var);

printf("Type a string: "); (void) fflush(stdout);
bytes_read = getline (&var2, &nbytes, stdin);
if(bytes_read == -1)
{
fprintf(stderr,"ERROR in line %d in return value from"
" getline()" newline, __LINE__);
(void) fflush(stderr);
exit(EXIT_FAILURE);
}

printf("The string is %s" newline, var2); (void) fflush(stdout);

free(var2);
exit(EXIT_SUCCESS);
}
does the job for those of us with a new enough gcc compiler.

Your problem, of course, was the part I replaced by the
getline()/sscanf() pair.
Everyone else: Think fgets()/sscanf() and allocated buffer
var2.
As to the why: scanf() and family just do not empty the
input buffer as you seem to expect but get only what
they want. getline() found the leftover '\n' and that was
it. So, if you want to do it with scanf(), you will have
to empty the input buffer line with s.th. like

while ( (c=getchar()) != EOF )
if (c=='\n')
break;

(not tested)

Cheers
Michael

[Default User]

Profetas wrote:

I know what is causing the problem, but I couldn't
find out why.

Which problem is that?

Brian Rodenborn

[Profetas]

>>

I know what is causing the problem, but I couldn't
find out why.

Which problem is that?

after the scanf is edxecuted it won't execute the getline

bash-2.05b$ ./a.out
Type a number:12
The number is 12
Type a string:The string is

[Profetas]

>Your problem, of course, was the part I replaced by the

getline()/sscanf() pair.
Everyone else: Think fgets()/sscanf() and allocated buffer
var2.
As to the why: scanf() and family just do not empty the
input buffer as you seem to expect but get only what
they want. getline() found the leftover '\n' and that was
it. So, if you want to do it with scanf(), you will have
to empty the input buffer line with s.th. like

That is what I was looking for.

Thanks Michael Mair

[Default User]

Profetas wrote:

I know what is causing the problem, but I couldn't
find out why.

Which problem is that?

after the scanf is edxecuted it won't execute the getline

bash-2.05b$ ./a.out
Type a number:12
The number is 12
Type a string:The string is

http://www.eskimo.com/~scs/C-faq/q12.18.html


Brian Rodenborn

[Jack Klein]

On Wed, 18 Aug 2004 11:01:45 -0400, "Profetas" <xu*****@yahoo.com>
wrote in comp.lang.c:

I know what is causing the problem, but I couldn't
find out why.
There is no version of standard C where this is a legal program.
main(){
The implicit int return type of main() is illegal from C99 onward.
int var;
printf("Type a number:");
[snip]
char *var2;
Defining a variable after executable statements in a block is only
legal from C99 onward.

And as for these:
#define newline "\n"
#define question_mark "\?"
#define single_quotas "\'"
#define double_quotas "\""
#define form_feed "\f"
#define horizontal_tab "\t"
#define vertical_tab "\v"
#define backslash "\\"

The standard doesn't allow it, but my opinion is that any program
written by anyone who writes macros this dumb should automatically
fail.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Keith Thompson]

Jack Klein <ja*******@spamcop.net> writes:

On Wed, 18 Aug 2004 11:01:45 -0400, "Profetas" <xu*****@yahoo.com>
wrote in comp.lang.c: [...] And as for these:

#define newline "\n"

[snip] The standard doesn't allow it, but my opinion is that any program
written by anyone who writes macros this dumb should automatically
fail.

I think you meant "The standard *does* allow it...".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[CBFalconer]

Keith Thompson wrote:

Jack Klein <ja*******@spamcop.net> writes:

"Profetas" <xu*****@yahoo.com> wrote in comp.lang.c:

[...]

And as for these:

#define newline "\n"

[snip]

The standard doesn't allow it, but my opinion is that any program
written by anyone who writes macros this dumb should automatically
fail.

I think you meant "The standard *does* allow it...".

I think he means the standard doesn't allow automatic failing of
extremely dumb programs.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Keith Thompson]

CBFalconer <cb********@yahoo.com> writes:

Keith Thompson wrote:

Jack Klein <ja*******@spamcop.net> writes:

"Profetas" <xu*****@yahoo.com> wrote in comp.lang.c:

[...]

And as for these:

#define newline "\n"

[snip]

The standard doesn't allow it, but my opinion is that any program
written by anyone who writes macros this dumb should automatically
fail.

I think you meant "The standard *does* allow it...".

I think he means the standard doesn't allow automatic failing of
extremely dumb programs.

I think you're right. And so was he. And so am I (now).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Profetas]

>The standard doesn't allow it, but my opinion is that any program

written by anyone who writes macros this dumb should automatically

fail.

How do you know that it is dumb, if you don't even know the
rest of my program, and you don't know why it has been used
and its purpose, and how it has been written

don't judge what you don't know.

[Dan Pop]

In <25******************************@localhost.talkab outprogramming.com> "Profetas" <xu*****@yahoo.com> writes:

The standard doesn't allow it, but my opinion is that any program
written by anyone who writes macros this dumb should automaticallyfail.

How do you know that it is dumb, if you don't even know the
rest of my program, and you don't know why it has been used
and its purpose, and how it has been written

It is obvious, to anyone with a clue, that those macro definitions can
serve no good purpose in *any* C program.
don't judge what you don't know.

The judgment was entirely based on known things. Feel free to prove it
wrong by showing an example of good usage for those macros.

Here's an example of sensible macro:

#define SEPARATOR ','

and one of idiotic macro:

#define COMMA ','

The need to change the definition of SEPARATOR later in program's life is
conceivable, but there is no such need for a macro named COMMA.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Thomas Matthews]

Profetas wrote:

I know what is causing the problem, but I couldn't
find out why.

#define newline "\n"
#define question_mark "\?"
#define single_quotas "\'"
#define double_quotas "\""
#define form_feed "\f"
#define horizontal_tab "\t"
#define vertical_tab "\v"
#define backslash "\\"

One of the main problems of the above macros is
that you are using strings instead of characters.

If I have:
const char statement[] = "Hello\t\"World?\"";
And I want to search for a "question_mark",
I would naturally want to use:
char * posn;
posn = strchr(statement, question_mark);
Which will not work because strchr() requires
a single char as the second parameter. Also,
this one will be hard to find:
posn = strchr(question_mark, statement);
In the above line, the first parameter has the
correct type, but wrong logic.

Also, please check your spelling. Note that
in English, "quota" and "quote" are two different
words. A quota is a limit. One could have a
single quota. There could also be double quotas,
which means having two limits; which is far from
the symbol (").

At some point, macros lead more to obfuscating
a program than to readablility.
If you want to keep down this path, may I also
suggest these macros:
#define begin {
#define end }
#ifndef and
#define and &&
#endif
#ifndef or
#define or ||
#endif
#ifndef not
#define not !
#endif
#define ever 1
#define forever 1

while (forever)
begin
if (a and b)
begin
continue;
end
else
begin
break;
end
end
--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book

[Christopher Benson-Manica]

Profetas <xu*****@yahoo.com> spoke thus:

How do you know that it is dumb, if you don't even know the
rest of my program, and you don't know why it has been used
and its purpose, and how it has been written

Hang around here long enough and you'll realize that when certain
people (the eminent Mr. Klein being among them) call something you've
done "dumb", they're probably right. Lord knows it's happened to me
enough to know :)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Christopher Benson-Manica]

Jack Klein <ja*******@spamcop.net> spoke thus:

The standard doesn't allow it, but my opinion is that any program
written by anyone who writes macros this dumb should automatically
fail.

#define Splat '*'

(a real line of source code here)

It's definitely dubious :)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Dave Thompson]

On Thu, 19 Aug 2004 14:47:16 GMT, Thomas Matthews
<Th****************************@sbcglobal.net> wrote:

Profetas wrote:

#define newline "\n"

<etc>
One of the main problems of the above macros is
that you are using strings instead of characters.

Maybe. The only one the OP actually uses is as a string.

You (i.e. everyone) certainly should understand the difference between
(single) char and string (array of char, null terminated), and if you
need char's #define them -- if you #define at all; as others have
noted, these macros for obvious constants aren't very valuable.

But if you (may) need both, it's easier to get a char from a string
"\n" and *"\n' or possibly "\n"[0]
than it is to get a string from a char, which is impossible in C89
without introducing a variable and in C99 requires the clumsy
(/*const*/ char []){ '\n' }
- David.Thompson1 at worldnet.att.net

[ozbear]

On Thu, 26 Aug 2004 05:22:23 GMT, Dave Thompson
<da*************@worldnet.att.net> wrote:

On Thu, 19 Aug 2004 14:47:16 GMT, Thomas Matthews
<Th****************************@sbcglobal.net> wrote:

Profetas wrote:

> #define newline "\n"

<etc>

One of the main problems of the above macros is
that you are using strings instead of characters.

Maybe. The only one the OP actually uses is as a string.

You (i.e. everyone) certainly should understand the difference between
(single) char and string (array of char, null terminated), and if you
need char's #define them -- if you #define at all; as others have
noted, these macros for obvious constants aren't very valuable.

The difference becomes specious and/or non-existent in the case
of a single char which contains '\0' as its value.

Given a definition
char mychar = '0';

and passing &mychar to a function expecting "string" is legal.

It is therefore both a single char and a 0-terminated string.

It is purely a point-of-view thing.

Oz
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Dan Pop]

In <412db9b1.125692140@news-server> oz****@bigpond.com (ozbear) writes:

The difference becomes specious and/or non-existent in the case
of a single char which contains '\0' as its value.

Given a definition
char mychar = '0';

You've been correct in the plain English text, but not in the C code:
'\0' and '0' are completely different things, so make it:

char mychar = '\0';

To avoid this mistake (probably a typo in Oz's case), I simply never
bother using '\0'. A plain 0 will not leave any place for doubts when
used in a character context and mistyping '0' when you mean 0 (or vice
versa) is highly unlikely (this typically happens due to a thinko).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[ozbear]

On 26 Aug 2004 13:01:26 GMT, Da*****@cern.ch (Dan Pop) wrote:

In <412db9b1.125692140@news-server> oz****@bigpond.com (ozbear) writes:

The difference becomes specious and/or non-existent in the case
of a single char which contains '\0' as its value.

Given a definition
char mychar = '0';

You've been correct in the plain English text, but not in the C code:
'\0' and '0' are completely different things, so make it:

char mychar = '\0';

To avoid this mistake (probably a typo in Oz's case), I simply never
bother using '\0'. A plain 0 will not leave any place for doubts when
used in a character context and mistyping '0' when you mean 0 (or vice
versa) is highly unlikely (this typically happens due to a thinko).

Hmmm... dunno where the '\' went but indeed it was a typo.
Using the unadorned 0 is a better idea, at least in this case.
Thanks for the correction.

Oz
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[William L. Bahn]

"ozbear" <oz****@bigpond.com> wrote in message
news:412f0cfb.212550031@news-server...

On 26 Aug 2004 13:01:26 GMT, Da*****@cern.ch (Dan Pop) wrote:

In <412db9b1.125692140@news-server> oz****@bigpond.com (ozbear) writes:

The difference becomes specious and/or non-existent in the caseof a single char which contains '\0' as its value.

Given a definition
char mychar = '0';

You've been correct in the plain English text, but not in the C code:'\0' and '0' are completely different things, so make it:

char mychar = '\0';

To avoid this mistake (probably a typo in Oz's case), I simply neverbother using '\0'. A plain 0 will not leave any place for doubts whenused in a character context and mistyping '0' when you mean 0 (or viceversa) is highly unlikely (this typically happens due to a thinko).

Hmmm... dunno where the '\' went but indeed it was a typo.
Using the unadorned 0 is a better idea, at least in this case.
Thanks for the correction.

This can be argued both ways:

IF the goal is to write code based on defined behavior (as
opposed to defined implementation), then mychar = 0 should be
avoided because it relies on a detailed knowledge of the
implementation requirements for the NUL character.

HOWEVER, by using that knowledge (which the next person reading
the code may not have) an easy to make and hard to find logic
error can be avoided.

[Arthur J. O'Dwyer]

On Fri, 27 Aug 2004, William L. Bahn wrote:

On 26 Aug 2004 13:01:26 GMT, Da*****@cern.ch (Dan Pop) wrote:

To avoid this mistake (probably a typo in Oz's case), I simply
never bother using '\0'. A plain 0 will not leave any place for
doubts when used in a character context and mistyping '0' when you
mean 0 (or vice versa) is highly unlikely (this typically happens
due to a thinko).

This can be argued both ways:

IF the goal is to write code based on defined behavior (as
opposed to defined implementation), then mychar = 0 should be
avoided because it relies on a detailed knowledge of the
implementation requirements for the NUL character.

HOWEVER, by using that knowledge (which the next person reading
the code may not have) an easy to make and hard to find logic
error can be avoided.

I don't think you understand. The integer constants 0, '\0', 0x0,
00000, and (1/42) are all equivalent, by definition. It doesn't
matter what implementation you're using. Zero is zero, according
to the Standard.

So the only question is, when do you prefer to use which "flavor"
of zero? And that's purely a style decision.

For the record, I've never encountered the '\0' <==> '0' bug Dan
mentioned, but I can definitely see how it could be a problem. But
no bigger problem than mistyping '(int)123' for '(int)213' or something.
I'm not changing my religion over it. ;)

-Arthur

[Dan Pop]

In <10*************@corp.supernews.com> "William L. Bahn" <wi*****@toomuchspam.net> writes:

"ozbear" <oz****@bigpond.com> wrote in message
news:412f0cfb.212550031@news-server...

On 26 Aug 2004 13:01:26 GMT, Da*****@cern.ch (Dan Pop) wrote:

>In <412db9b1.125692140@news-server> oz****@bigpond.com(ozbear) writes: >
>>The difference becomes specious and/or non-existent in thecase >>of a single char which contains '\0' as its value.
>>
>>Given a definition
>> char mychar = '0';
>
>You've been correct in the plain English text, but not in theC code: >'\0' and '0' are completely different things, so make it:
>
> char mychar = '\0';
>
>To avoid this mistake (probably a typo in Oz's case), I simplynever >bother using '\0'. A plain 0 will not leave any place fordoubts when >used in a character context and mistyping '0' when you mean 0(or vice >versa) is highly unlikely (this typically happens due to athinko). >

Hmmm... dunno where the '\' went but indeed it was a typo.
Using the unadorned 0 is a better idea, at least in this case.
Thanks for the correction.

This can be argued both ways:

IF the goal is to write code based on defined behavior (as
opposed to defined implementation), then mychar = 0 should be
avoided because it relies on a detailed knowledge of the
implementation requirements for the NUL character.

Please enlighten us about the differences between 0 and '\0'.
Ditto about the implementation requirements for the null character.

In my naivety, I thought that 0 and '\0' have the same type and
value on any conforming implementation and that the null character
is fully specified by the language definition. What am I missing?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <Pi**********************************@unix41.andre w.cmu.edu> "Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:

For the record, I've never encountered the '\0' <==> '0' bug Dan
mentioned, but I can definitely see how it could be a problem. But

I mentioned it in a post including code posted by Oz that contained
an instance of that very bug!

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[ozbear]

On 27 Aug 2004 16:18:58 GMT, Da*****@cern.ch (Dan Pop) wrote:

In <Pi**********************************@unix41.andre w.cmu.edu> "Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:

For the record, I've never encountered the '\0' <==> '0' bug Dan
mentioned, but I can definitely see how it could be a problem. But

I mentioned it in a post including code posted by Oz that contained
an instance of that very bug!

Indeed....an example of an attempt at "clarity" doing exactly the
opposite of what was intended.

Time to grep for '0'... :O)

Oz
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?