Hi,
>>"Steve" == Steve Greenland <[EMAIL PROTECTED]> writes:
Steve> On 10-Apr-98, 18:00 (CDT), Manoj Srivastava
Steve> <[EMAIL PROTECTED]> wrote:
>> I have looked at the standards to shed some liight on this
>> subject, and I failt to see any statements that a second flose is
>> cause for undefined behaviour, asuming you meant the technical term
>> ``undefined'' when you say "not defined".
Steve> My copy of the standard is at work, but I think there's a
Steve> statement near the beginning of the <stdio.h> section that says
Steve> calling any of the I/O functions with an invalid FILE * is
Steve> causes undefined behaviour. If anybody really cares, I'll look
Steve> Monday.
Please look further in my message, I do prove that indeed this
is undefined behaviour. The above paragraph is my mind taking a
vacation.
>> >> A double fclose is just as bad as a double free() and is not a
>> library error should it fault or corrupt memory.
>>
>> Hola! Corupting memory is not acceptable behaviour! (Unless you
>> document this)
Steve> Sure it is. Go read the definition of "undefined behaviour"
Steve> again -- "this standard imposes no requirment". It can corrupt
Steve> memory, re-format your hard disk, or make monkeys fly out of
Steve> your nose; all of these are ISO C compliant.
----------------------------------------------------------------------
1.6 Definitions of terms
o Undefined Behaviour -- behaviour, upon the use of a nonportable or
erroneous program construct, of erroneous data, or of inderminately
valued objects, for which the standard imposes no
requirements. Permissible undefined behaviour ranges from ignoring
the situation completely with unpredictable results, to behaving
during translation or program execution in a documented manner
charecteristic of the environment (with or without the issuance of a
diagnostic message), to terminating a translation or execution (with
the issuance of a diagnostic message).
If a "shall" or "shall not" requirements that appears outside
of a constraint is violated, the behaviour is undefined. Undefined
behaviour is otherwise indicated in this standard by the words
"undefined behaviour" or by the omission of any explicit definition
of behavior. There is no difference in emphasis among these three;
they all describe "behaviour that is undefined."
o Unspecified behaviour -- behaviour, for a correct program construct
and correct data, for which the standard explicitly imposes no
requirements.
______________________________________________________________________
Please show why my statement is incorrect wrt to the above
statement from the C standard. I said: "Corupting memory is not
acceptable behaviour! (Unless you document this)". The standard says
"permissible undefined behaviour ..."
I understand that it is fashionable in comp.lang.c to say that
undefined behaviour means "It can corrupt memory, re-format your hard
disk, or make monkeys fly out of your nose; all of these are ISO C
compliant.", but the standard does make a statement about permissible
undefined behaviour, and unless such action is documented, it is not
permitted by the standard.
manoj
--
In article ... [EMAIL PROTECTED] (Wee Willie) writes: Well
I guess the summary says it all, where do I find Sports Illustrated
GIF's or anything similar ???? I violate copyright and I'm OK, I
view all night and I scan all day. He violates copyright and he's OK,
he views all night and he scans all day. I buy magazines at the
corner store, When I've scanned them all, I'll buy some more. He buys
magazines at the corner store, When he's scanned them all he'll buy
some more. Well, you get the idea... J Eric Townsend
([EMAIL PROTECTED])
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
