diff o/p

[aarklon]

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

int main(void)
{
int x; char ch;
char string[20] = "100 5";

sscanf(string,"%3d%c",&x,&ch);
printf("\n... %d %c",x,ch);

return EXIT_SUCCESS;
}

is giving o/p ... 100, that's ok but,

but
sscanf(string,"%3d%2c",&x,&ch);
printf("\n... %d %c",x,ch);

is giving o/p ... 53 , why ....????

[Barry Schwarz]

On Sun, 20 Apr 2008 09:05:47 -0700 (PDT), aa*****@gmail.com wrote:

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

int main(void)
{
int x; char ch;
char string[20] = "100 5";

sscanf(string,"%3d%c",&x,&ch);
printf("\n... %d %c",x,ch);

return EXIT_SUCCESS;
}

is giving o/p ... 100, that's ok but,

The actual output should be "... 100 " (note the two trailing blanks,
one is hard coded in your format string and the other is the value of
ch).

>
but
sscanf(string,"%3d%2c",&x,&ch);
printf("\n... %d %c",x,ch);

is giving o/p ... 53 , why ....????

Because you invoked undefined behavior.

Your %2c promises sscanf that &ch points to an array of at least 2
char. Does it? The first character (the blank) goes into wherever
&ch points (obviously into ch). The next character (the '5') goes
into the next byte beyond ch. You have overflowed your one character
buffer.

[O/T] You apparently have a little endian ASCII machine and x follows
ch in memory. After scanning the 100, x contains 0x64 0x00 ... 0x00.
After scanning the blank, ch contains 0x20. After scanning the '5', x
contains 0x35 0x00 ... 0x00. This is the ASCII representation of the
character 5 and the binary representation of the number 53.
Remove del for email

[CBFalconer]

aa*****@gmail.com wrote:

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

int main(void) {
int x; char ch;
char string[20] = "100 5";

sscanf(string,"%3d%c",&x,&ch);
printf("\n... %d %c",x,ch);
return EXIT_SUCCESS;
}

is giving o/p ... 100, that's ok but,

but
sscanf(string,"%3d%2c",&x,&ch);
printf("\n... %d %c",x,ch);

is giving o/p ... 53 , why ....????

Why have you discarded the return values from sscanf()? Capture
them and analyze them.

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

** Posted from http://www.teranews.com **

[aarklon]

On Apr 21, 4:06*am, CBFalconer <[e-mail]:

>
Why have you discarded the return values from sscanf()? *Capture
them and analyze them.

from lcc-win32 standard library , i have the following

the sscanf function returns the value of the macro EOF if an input
failure occurs before any conversion. otherwise, the sscanf function
returns the number of input items assigned,which can be fewer than
provided for, or even zero,in the event of an early matching failure

now
printf("\n %d",sscanf(string,"%3d%2c",&x,&ch)); is giving 2,

so I don't think there is any thing wrong with the return type of
sscanf

[santosh]

aa*****@gmail.com wrote:

On Apr 21, 4:06*am, CBFalconer <[e-mail]:

>>
Why have you discarded the return values from sscanf()? *Capture
them and analyze them.

from lcc-win32 standard library , i have the following

the sscanf function returns the value of the macro EOF if an input
failure occurs before any conversion. otherwise, the sscanf function
returns the number of input items assigned,which can be fewer than
provided for, or even zero,in the event of an early matching failure

now
printf("\n %d",sscanf(string,"%3d%2c",&x,&ch)); is giving 2,

so I don't think there is any thing wrong with the return type of
sscanf

CBFalconer is saying that it is good practise to check all functions
that return a status code for *possible* errors. Yes, in this case the
call is successful, but the point is to code in the error checking code
as a matter of course. It's more work but it's necessary to do only
once and pays of the long run, at least for all non-trivial programs.

[Keith Thompson]

aa*****@gmail.com writes:

On Apr 21, 4:06*am, CBFalconer <[e-mail]:

>Why have you discarded the return values from sscanf()? *Capture
them and analyze them.

from lcc-win32 standard library , i have the following

the sscanf function returns the value of the macro EOF if an input
failure occurs before any conversion. otherwise, the sscanf function
returns the number of input items assigned,which can be fewer than
provided for, or even zero,in the event of an early matching failure

now
printf("\n %d",sscanf(string,"%3d%2c",&x,&ch)); is giving 2,

so I don't think there is any thing wrong with the return type of
sscanf

Nobody said there was anything wrong with the return type. The
problem is that, in the code you posted upthread, you call sscanf()
and discard the result it returns.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard]

santosh <sa*********@gmail.comwrites:

aa*****@gmail.com wrote:

>On Apr 21, 4:06Â*am, CBFalconer <[e-mail]:

>>>
Why have you discarded the return values from sscanf()? Â*Capture
them and analyze them.

from lcc-win32 standard library , i have the following

the sscanf function returns the value of the macro EOF if an input
failure occurs before any conversion. otherwise, the sscanf function
returns the number of input items assigned,which can be fewer than
provided for, or even zero,in the event of an early matching failure

now
printf("\n %d",sscanf(string,"%3d%2c",&x,&ch)); is giving 2,

so I don't think there is any thing wrong with the return type of
sscanf

CBFalconer is saying that it is good practise to check all functions
that return a status code for *possible* errors. Yes, in this case the

There comes a point in all development where you KNOW the data is
contained and that the standard library functions "just works". It is
not "good practice" to check all error codes - it overly bloats the code
and makes it hard to read due to it being overly wordy.

If you were to error check each and every function call you would be
there all day.

I realise its very easy for the self righteous to argue against this but
I can not remember, for example, the last time I checked the return code
for, say, printf.

call is successful, but the point is to code in the error checking code
as a matter of course. It's more work but it's necessary to do only
once and pays of the long run, at least for all non-trivial programs.

Check non trivial things. Not the trivial things.

[santosh]

Richard wrote:

santosh <sa*********@gmail.comwrites:

>aa*****@gmail.com wrote:

>>On Apr 21, 4:06*am, CBFalconer <[e-mail]:
Why have you discarded the return values from sscanf()? *Capture
them and analyze them.

from lcc-win32 standard library , i have the following

the sscanf function returns the value of the macro EOF if an input
failure occurs before any conversion. otherwise, the sscanf function
returns the number of input items assigned,which can be fewer than
provided for, or even zero,in the event of an early matching failure

now
printf("\n %d",sscanf(string,"%3d%2c",&x,&ch)); is giving 2,

so I don't think there is any thing wrong with the return type of
sscanf

CBFalconer is saying that it is good practise to check all functions
that return a status code for *possible* errors. Yes, in this case
the

There comes a point in all development where you KNOW the data is
contained and that the standard library functions "just works". It is
not "good practice" to check all error codes - it overly bloats the
code and makes it hard to read due to it being overly wordy.

If you were to error check each and every function call you would be
there all day.

I realise its very easy for the self righteous to argue against this
but I can not remember, for example, the last time I checked the
return code for, say, printf.

Unless say stdout were to be associated with a disk file through
freopen. Seldom done, but not inconceivable.

>call is successful, but the point is to code in the error checking
code as a matter of course. It's more work but it's necessary to do
only once and pays of the long run, at least for all non-trivial
programs.

Check non trivial things. Not the trivial things.

Personally I check all functions that _can_ fail, even if the response
is merely a short log entry followed by exit or abort.

You wouldn't be there all day as this needs to be done only once and
maintained thereafter.

[Richard]

santosh <sa*********@gmail.comwrites:

Richard wrote:

>santosh <sa*********@gmail.comwrites:

>>aa*****@gmail.com wrote:

On Apr 21, 4:06Â*am, CBFalconer <[e-mail]:

>
Why have you discarded the return values from sscanf()? Â*Capture
them and analyze them.

from lcc-win32 standard library , i have the following

the sscanf function returns the value of the macro EOF if an input
failure occurs before any conversion. otherwise, the sscanf function
returns the number of input items assigned,which can be fewer than
provided for, or even zero,in the event of an early matching failure

now
printf("\n %d",sscanf(string,"%3d%2c",&x,&ch)); is giving 2,

so I don't think there is any thing wrong with the return type of
sscanf

CBFalconer is saying that it is good practise to check all functions
that return a status code for *possible* errors. Yes, in this case
the

There comes a point in all development where you KNOW the data is
contained and that the standard library functions "just works". It is
not "good practice" to check all error codes - it overly bloats the
code and makes it hard to read due to it being overly wordy.

If you were to error check each and every function call you would be
there all day.

I realise its very easy for the self righteous to argue against this
but I can not remember, for example, the last time I checked the
return code for, say, printf.

Unless say stdout were to be associated with a disk file through
freopen. Seldom done, but not inconceivable.

>>call is successful, but the point is to code in the error checking
code as a matter of course. It's more work but it's necessary to do
only once and pays of the long run, at least for all non-trivial
programs.

Check non trivial things. Not the trivial things.

Personally I check all functions that _can_ fail, even if the response
is merely a short log entry followed by exit or abort.

All functions "can fail". But if some fail then the chance of recovery
is often zero. printf can fail. But what to do if it does? Some common
sense is needed here.

What "can fail"? Let me try to suggest common sense things ---

Clearly anything dealing with say pluggable media or random input would
need checking. But the claim that all functions should be checked is
blatant nonsense.

You wouldn't be there all day as this needs to be done only once and
maintained thereafter.

For a limited set of functions it makes sense to check of course.

[Ben Bacarisse]

Richard <de***@gmail.comwrites:

Check non trivial things. Not the trivial things.

The context was input to the program. It is very rare for an input
error to be a trivial thing. By all means ignore what printf returns,
but the return from the scanf family is much more useful.

--
Ben.

[Ben Bacarisse]

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

Richard <de***@gmail.comwrites:

>Check non trivial things. Not the trivial things.

The context was input to the program.

No, scratch that. The contex was sscanf of a literal string. That is
an odd enough thing to do that the can be no general rules about it.

It is very rare for an input
error to be a trivial thing. By all means ignore what printf returns,
but the return from the scanf family is much more useful.

I stand by the general idea. Input errors are rarely trivial.

--
Ben.

[Richard]

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

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

>Richard <de***@gmail.comwrites:

>>Check non trivial things. Not the trivial things.

The context was input to the program.

No, scratch that. The contex was sscanf of a literal string. That is
an odd enough thing to do that the can be no general rules about it.

> It is very rare for an input
error to be a trivial thing. By all means ignore what printf returns,
but the return from the scanf family is much more useful.

I stand by the general idea. Input errors are rarely trivial.

I distinctly stated just that in a reply to santosh. "Random
input". Input from a file is normally controlled and pre formatted
however. In large simulation SW I have been involved in we would
probably check the error codes simply for EOF type conditions every X
lines where we know that the X lines must be there since the scenario
generator would otherwise have flagged an error while creating it and
"X" is the number of lines in a process cycle. Checking the format
and/or existence of each field in those X lines would be considered
unnecessary due to its pre formatted nature. End of the world if you do?
No. Necessary? No.

Bottom line - its not necessary or desirable to check the return code
of each and every function you call as was or appeared to be suggested.

[santosh]

Richard wrote:

<snip>

All functions "can fail". But if some fail then the chance of recovery
is often zero. printf can fail. But what to do if it does? Some common
sense is needed here.

It may be possible to write out an error message to another stream, and
this would be useful in the rare case that something like this does
happen. Then you don't need to go hunting all over the program or step
painfully through a debugger.

What "can fail"? Let me try to suggest common sense things ---

Clearly anything dealing with say pluggable media or random input
would need checking. But the claim that all functions should be
checked is blatant nonsense.

Well, my opinion is that functions return a status code for a purpose.
They should be checked in any serious programming project. For example
programs of course, many of these checks can be skipped, but some
functions have a particularly high rate of misuse or are highly
fastidious. The scanf family is a prime example. Sscanf is a lot better
than scanf, but it can still fail on incorrect strings.

>You wouldn't be there all day as this needs to be done only once and
maintained thereafter.

For a limited set of functions it makes sense to check of course.

[santosh]

Richard wrote:

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

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

>>Richard <de***@gmail.comwrites:

Check non trivial things. Not the trivial things.

The context was input to the program.

No, scratch that. The contex was sscanf of a literal string. That is
an odd enough thing to do that the can be no general rules about it.

>> It is very rare for an input
error to be a trivial thing. By all means ignore what printf
returns, but the return from the scanf family is much more useful.

I stand by the general idea. Input errors are rarely trivial.

I distinctly stated just that in a reply to santosh. "Random
input". Input from a file is normally controlled and pre formatted
however. In large simulation SW I have been involved in we would
probably check the error codes simply for EOF type conditions every X
lines where we know that the X lines must be there since the scenario
generator would otherwise have flagged an error while creating it and
"X" is the number of lines in a process cycle. Checking the format
and/or existence of each field in those X lines would be considered
unnecessary due to its pre formatted nature. End of the world if you
do? No. Necessary? No.

Bottom line - its not necessary or desirable to check the return code
of each and every function you call as was or appeared to be
suggested.

You are talking about program specific functions. I was talking about
the standard library functions: that I check all standard library
functions that have a possibility of failure, mainly through
pre-written wrappers.

[Richard]

santosh <sa*********@gmail.comwrites:

Richard wrote:

<snip>

>All functions "can fail". But if some fail then the chance of recovery
is often zero. printf can fail. But what to do if it does? Some common
sense is needed here.

It may be possible to write out an error message to another stream, and
this would be useful in the rare case that something like this does
happen. Then you don't need to go hunting all over the program or step
painfully through a debugger.

Possibly in "debug phase".

>

>What "can fail"? Let me try to suggest common sense things ---

Clearly anything dealing with say pluggable media or random input
would need checking. But the claim that all functions should be
checked is blatant nonsense.

Well, my opinion is that functions return a status code for a purpose.
They should be checked in any serious programming project. For example

In an ideal world where everyone is a shiny faced newbie possibly.

programs of course, many of these checks can be skipped, but some
functions have a particularly high rate of misuse or are highly
fastidious. The scanf family is a prime example. Sscanf is a lot
better

Isn't this what I said? As usual you seem to obfuscate things, in an
almost Heathfieldesque manner, to try and have the upper hand on the
last word. I distinctly said there are functions and situations you
would consider checking. My point is that this is not ALL of the time.

Yet you seem to hint it should be ALL of the time time when you said,
rather self righteously,

,----
| "Well, my opinion is that functions return a status code for a purpose."
`----

Yes. We know.

than scanf, but it can still fail on incorrect strings.

Yes. We know. In fact I would be surprised if it did NOT fail on
incorrect strings. My point is that there are many times where there can
not seriously be an incorrect string. And this function is just one
such example.

Checking ALL function returns is nonsense and I have never seen it in
any but the most trivial SW project. The frameworks are developed so
that you do not need to check many returns. And by framework I mean the
code and input data suite.

>

>>You wouldn't be there all day as this needs to be done only once and
maintained thereafter.

For a limited set of functions it makes sense to check of course.

[Richard]

santosh <sa*********@gmail.comwrites:

Richard wrote:

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

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

Richard <de***@gmail.comwrites:

Check non trivial things. Not the trivial things.

The context was input to the program.

No, scratch that. The contex was sscanf of a literal string. That is
an odd enough thing to do that the can be no general rules about it.

It is very rare for an input
error to be a trivial thing. By all means ignore what printf
returns, but the return from the scanf family is much more useful.

I stand by the general idea. Input errors are rarely trivial.

I distinctly stated just that in a reply to santosh. "Random
input". Input from a file is normally controlled and pre formatted
however. In large simulation SW I have been involved in we would
probably check the error codes simply for EOF type conditions every X
lines where we know that the X lines must be there since the scenario
generator would otherwise have flagged an error while creating it and
"X" is the number of lines in a process cycle. Checking the format
and/or existence of each field in those X lines would be considered
unnecessary due to its pre formatted nature. End of the world if you
do? No. Necessary? No.

Bottom line - its not necessary or desirable to check the return code
of each and every function you call as was or appeared to be
suggested.

You are talking about program specific functions. I was talking about
the standard library functions: that I check all standard library
functions that have a possibility of failure, mainly through
pre-written wrappers.

Good luck to you on that then. I would never do this in the great
majority of standard library functions - its total code bloat. They are
standard functions for a reason - they work as standard :-; Clearly
functions which return a number or index are a different kettle of fish.

I suspect we are not too far from agreeing - you are just not willing to
see my "not all the time" with the respect it's due. I'm not being
unprofessional or stupid with this claim - just practical.

[santosh]

Richard wrote:

santosh <sa*********@gmail.comwrites:

>Richard wrote:

<snip>

>>All functions "can fail". But if some fail then the chance of
recovery is often zero. printf can fail. But what to do if it does?
Some common sense is needed here.

It may be possible to write out an error message to another stream,
and this would be useful in the rare case that something like this
does happen. Then you don't need to go hunting all over the program
or step painfully through a debugger.

Possibly in "debug phase".

>>

>>What "can fail"? Let me try to suggest common sense things ---

Clearly anything dealing with say pluggable media or random input
would need checking. But the claim that all functions should be
checked is blatant nonsense.

Well, my opinion is that functions return a status code for a
purpose. They should be checked in any serious programming project.
For example

In an ideal world where everyone is a shiny faced newbie possibly.

>programs of course, many of these checks can be skipped, but some
functions have a particularly high rate of misuse or are highly
fastidious. The scanf family is a prime example. Sscanf is a lot
better

Isn't this what I said? As usual you seem to obfuscate things, in an
almost Heathfieldesque manner, to try and have the upper hand on the
last word. I distinctly said there are functions and situations you
would consider checking. My point is that this is not ALL of the time.

Okay.

Yet you seem to hint it should be ALL of the time time when you said,
rather self righteously,

,----
| "Well, my opinion is that functions return a status code for a
| purpose."
`----

Yes. We know.

>than scanf, but it can still fail on incorrect strings.

Yes. We know. In fact I would be surprised if it did NOT fail on
incorrect strings. My point is that there are many times where there
can not seriously be an incorrect string. And this function is just
one such example.

Note that the original context of the recommendation to check the return
code was the OP's use of sscanf on input from interactive source, which
should always be (IMO) checked for mistakes or deliberate misuse.

Granted if you are 100% sure that a certain file cannot contain
malformed line then there would be no necessity to put in the checks. I
personally would still check since the overhead of an integer compare
and branch is likely to be dwarfed by the file I/O latency. You never
know that the next release of the program might present a loophole for
in-advertant (or malicious) modifications.

Checking ALL function returns is nonsense and I have never seen it in
any but the most trivial SW project.

Haven't you got this backwards. I would normally expect a trivial s/w
project to ignore checks, not a serious, well designed one.

The frameworks are developed so
that you do not need to check many returns. And by framework I mean
the code and input data suite.

Yes. Many internal functions work on pre-checked data, and we can ignore
the checks for such functions, though asserts would still be useful, at
least during development. But I don't see any good reason not to check
interface and I/O functions, even if the possibility of failure is
minuscule (like in the case of puts etc.).

[Richard]

santosh <sa*********@gmail.comwrites:

Richard wrote:

>santosh <sa*********@gmail.comwrites:

>>Richard wrote:

<snip>

All functions "can fail". But if some fail then the chance of
recovery is often zero. printf can fail. But what to do if it does?
Some common sense is needed here.

It may be possible to write out an error message to another stream,
and this would be useful in the rare case that something like this
does happen. Then you don't need to go hunting all over the program
or step painfully through a debugger.

Possibly in "debug phase".

>>>
What "can fail"? Let me try to suggest common sense things ---

Clearly anything dealing with say pluggable media or random input
would need checking. But the claim that all functions should be
checked is blatant nonsense.

Well, my opinion is that functions return a status code for a
purpose. They should be checked in any serious programming project.
For example

In an ideal world where everyone is a shiny faced newbie possibly.

>>programs of course, many of these checks can be skipped, but some
functions have a particularly high rate of misuse or are highly
fastidious. The scanf family is a prime example. Sscanf is a lot
better

Isn't this what I said? As usual you seem to obfuscate things, in an
almost Heathfieldesque manner, to try and have the upper hand on the
last word. I distinctly said there are functions and situations you
would consider checking. My point is that this is not ALL of the time.

Okay.

>Yet you seem to hint it should be ALL of the time time when you said,
rather self righteously,

,----
| "Well, my opinion is that functions return a status code for a
| purpose."
`----

Yes. We know.

>>than scanf, but it can still fail on incorrect strings.

Yes. We know. In fact I would be surprised if it did NOT fail on
incorrect strings. My point is that there are many times where there
can not seriously be an incorrect string. And this function is just
one such example.

Note that the original context of the recommendation to check the return
code was the OP's use of sscanf on input from interactive source, which
should always be (IMO) checked for mistakes or deliberate misuse.

Granted if you are 100% sure that a certain file cannot contain
malformed line then there would be no necessity to put in the checks. I
personally would still check since the overhead of an integer compare
and branch is likely to be dwarfed by the file I/O latency. You never
know that the next release of the program might present a loophole for
in-advertant (or malicious) modifications.

>Checking ALL function returns is nonsense and I have never seen it in
any but the most trivial SW project.

Haven't you got this backwards. I would normally expect a trivial s/w
project to ignore checks, not a serious, well designed one.

Can you imagine if every call was if/then'd ? How the code would look?
How the real estate for functional lines would be?

>

>The frameworks are developed so
that you do not need to check many returns. And by framework I mean
the code and input data suite.

Yes. Many internal functions work on pre-checked data, and we can ignore
the checks for such functions, though asserts would still be useful,
at

asserts suck. They break the flow of the code IMO when reading it. This
is a practical preference developed over years of reading other peoples
code. I never liked them. Purely personal of course.

least during development. But I don't see any good reason not to check
interface and I/O functions, even if the possibility of failure is
minuscule (like in the case of puts etc.).

I see lots of reasons not to bother. Possibly you get too wrapped up in
minutiae - personally i like to read the code which does the work. I
find that code which checks things over zealously is often the least well
thought out. But to clarify - I dont check because I *know* the check is
worthless. The data going into the function is within bounds. The
function being called IS well defined. There can be NO error which one
can reasonably deal with. These comments taken in the context of other
disclaimers in the thread I hasten to add.

[CBFalconer]

santosh wrote:

Richard wrote:

>santosh <sa*********@gmail.comwrites:

.... snip ...

>>

>>CBFalconer is saying that it is good practise to check all
functions that return a status code for *possible* errors.

There comes a point in all development where you KNOW the data is
contained and that the standard library functions "just works".
It is not "good practice" to check all error codes - it overly
bloats the code and makes it hard to read due to it being overly
wordy.

Piggybacking. Note that Richard is a troll, to be ignored.

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

[lawrence.jones]

Richard <de***@gmail.comwrote:

>
All functions "can fail". But if some fail then the chance of recovery
is often zero. printf can fail. But what to do if it does?

Never check for an error you don't know how to handle. ;-)

-Larry Jones

It seems like once people grow up, they have no idea what's cool. -- Calvin