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]

#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

 

[aarklon]

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

 

[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,

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.

...................
but the buffer string is stored as |49|48|48|32|53|\0|
...................
how this scanning takes place is there any predefined order why ch is
not reading string[0],string[1] in that manner...????

 

[santosh]

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]

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.

 

[Richard]

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]

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.

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]

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


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]

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 Bacarisse]

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.

 

[Richard]

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.


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:

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.

 

[santosh]

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]

Richard wrote:



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".

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.

 

[Richard]

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.

 

[Richard]

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.


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?

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.

 

[Barry Schwarz]

#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.

...................
but the buffer string is stored as |49|48|48|32|53|\0|

Precisely. That is '1', '0', '0', ' ', '5' and a terminating nul. The
%3d picks up the '1', '0', '0' and converts it to an int value of 100
and stores it in x. The %2c picks up the ' ', stores it in ch, picks
up the '5', and attempts to store it in the byte following ch. THIS IS
UNDEFINED BEHAVIOR. You have overflowed your OUTPUT buffer, which is
the single char named ch. It has nothing to do with your array named
string which you apparently think of as an input buffer even though
you never do any input into it.

The off-topic question is where did the '5' get stored. I gave you a
reasonable explanation (not necessarily correct) consistent with the
behavior you described.

...................
how this scanning takes place is there any predefined order why ch is
not reading string[0],string[1] in that manner...????

Remove del for email

 

[lawrence.jones]

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