Re: Gcc warning instead of error
Re: Gcc warning instead of error
- Subject: Re: Gcc warning instead of error
- From: "Chris Jefferson" <email@hidden>
- Date: Wed, 23 Jul 2008 15:12:36 +0100
2008/7/23 Steve Checkoway <email@hidden>:
>
> On Jul 23, 2008, at 5:25 AM, Chris Jefferson wrote:
>
>> My reading of the last line of 1.3.13 is that if the compiler cannot
>> provide that undefined behaviour will occur (i.e., it cannot prove the
>> line of code with the non-POD call happens), then it is only allowed
>> to print a warning, not fail to compile. The text is however, like
>> most standard text, difficult to read!
>
>
> Section 1.3 in particular is written in a very strange manner and doesn't
> read well at all.
>
> I think that 1.3.12 is more relevant. It says the following. (Ugh, I don't
> have permission to copy from this PDF? Sorry Apple, but I will copy from any
> document I damn well please.)
>
>> 1.3.12 undefined behavior [defns.undefined]
>> behavior, such as might arise upon use of an erroneous program construct
>> or
>> erroneous data, for which this International Standard imposes no
>> requirements.
>> Undefined behavior may also be expected when this International Standard
>> omits
>> the description of any explicit definition of behavior. [Note: permissible
>> unde- fined behavior ranges from ignoring the situation completely with
>> unpredictable results, to behaving during translation or program execution
>> in a
>> documented manner characteristic of the environment (with or with- out the
>> issuance of a diagnostic message), to terminating a translation or
>> execution
>> (with the issuance of a diagnostic message). Many erroneous program
>> constructs
>> do not engender undefined behavior; they are required to be diagnosed. ]
>
Sorry, this is the bit I was quoting, I must have a differently
numbered document.
That last bit: "Many erroneous program constructs do not engender
undefined behavior; they are required to be diagnosed.", reads to me
as saying "If a program doesn not actually cause undefined behaviour,
you cannot reject it". Therefore an error could only be produced if it
could be proved the dodgy function call actually occurs, as unless the
function call actually occurs, I believe the program is valid (if
stupid).
Chris
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden