Re: socket api question - is it possible for recv() to receive 0byte from server? -- RPG400-L


On 20/11/2006, at 3:16 PM, Vernon Hamberg wrote:

Why? Because it is the generally accepted recommendation - as stated
by Jon Paris as follows in his "Who Knew You Could..." redbook:

1) But it's not a generally recommended practice in C programming anderrno is a C run-time attribute2) Jon wasn't the only author of that Red Book so it's possible thisrecommendation came from a different source.3) Even if Jon wrote the quote below I think he is wrong forrecommending it. My view is the same as Scott's on this one.

If you want to quote someone who knows what he's talking about** thenyou'd be hard-pressed to find a more authoritative source than W.Richard Stevens. From "Advanced Programming in the Unix Environment"""There are two rules to be aware of with respect to errno. First, itsvalue is never cleared by a routine if an error does not occur.Therefore, we should examine its value only when the return value froma function indicates that an error occurred. Second, the value of errnois never set to 0 by any of the functions, and none of the constantsdefined in <errno.h> have a value of 0."

To me that says that testing errno for a non-zero value is valid buttesting it for 0 is not valid.

** Not suggesting that Jon doesn't know what he's talking about but inthis particular case, if he is the originator of the quote to which yourefer, then he's wrong.

The error code is made available by the GetErrNo() function, which is a
remapped __error() C function. The GetErrNo() function gets access tothe ErrNovariable through a pointer. The ErrNo variable contains the errorcode. Beforeissuing any function that returns an error code, the ErrNo variableshould be
cleared. However, it is possible only after the GetErrNo() function
was performed.
If the error code is not cleared before the function is entered, the
resulting error
code may be false.

Only if you write code that checks errno without first checking thefunction return value to see if errno SHOULD be checked. If you do thatthen you are wrong.


errno - as I know you know - is a global variable used by everything
- it is not changed if not error occurs, so setting it to 0 just
before a function that might set it and then checking it after is how
I understand doing this.

You can't rely on the function you call AFTER setting errno to zero tobe the only thing that may change it. You and others are suggesting (ordefending):


set erro no to zero
call OS function X()
check errno is still zero

However you have no way of knowing what other functions are called byX(). It may call Y() which might fail and set errno. X() might handlethis condition and therefore return successfully leaving errno towhatever Y() set it. Checking errno to determine success or failure inthis case is obviously flawed.

A similar situation can happen in application code that wraps multipleOS functions into one higher-level function--especially if it handlesthe error condition. Unless you have the practice of always resettingerrno to zero after testing it you run the risk of getting a falseerror condition. Note that IF you did this sort of thing you would beflouting existing convention regarding errno.

Because you CANNOT know what happens to errno after you call an OSfunction the only thing you can do is check the function return valuefor an error indication PRIOR to testing errno.


Not all functions return an error code - an example is StrToD - it
returns a float value - it is commonly used to test whether a string
is numeric - the only reliable test for errors is to set errno - the

global variable - before calling StrToD and then checking it after thecall.

strtod() is not a very reliable way of determining if a string isnumeric. Like most of these C conversion functions it makes a besteffort and never actually fails. It simply stops checking when it findsa character that is not a valid digit. strtod() does have two pseudoerror conditions:

        a) overflow
        b) underflow

Overflow returns HUGE_VAL. Underflow returns zero. In these cases errnomight be set to ERANGE but not always. So checking result for +HUGE_VALor -HUGE_VAL or zero might indicate an error. HUGE_VAL is probably anerror but zero is a valid floating point value so might not indicate anerror. I've had strtod() return zero in an underflow condition buterrno has remained at zero. No way to tell whether zero is the correctresult. Given that errno is not always set by this function it's notreliable to rely on it.

If you do use strtod() to check for a numeric string it is the endptrstring that must be checked, not the return value. Because the returnvalue is the only thing that MIGHT be affected by errno it follows thaterrno can't be reliably used on its own either and certainly not todetermine whether a string is numeric.


Tightly coupling the setting and checking will not cause problems
with other functions, as far as I know.


See suggested example above.


Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists

   http://www.flybynight.com.au/
   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175                                   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------