Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > [Q] UB query

Reply
Thread Tools

[Q] UB query

 
 
Simon P Simonson
Guest
Posts: n/a
 
      12-26-2009
In the following code,

1 main()
2 {
3 auto a;
4 volatile b;
5 (void) a;
6 (void) b;
7 }

is line 5 an undefined behavior? (I would say NO)

is line 6 an undefined behavior? (I would say YES)

Merry Xmas
SPS
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      12-26-2009
Simon P Simonson <(E-Mail Removed)> writes:
> In the following code,
>
> 1 main()
> 2 {
> 3 auto a;
> 4 volatile b;
> 5 (void) a;
> 6 (void) b;
> 7 }
>
> is line 5 an undefined behavior? (I would say NO)
>
> is line 6 an undefined behavior? (I would say YES)


First off, the code is written in an extremely archaic style; it's
not even legal in C99. In older versions of C, you could omit the
type on a declaration and it would default to int. There's no good
reason to do that.

int main(void)
{
int a;
volatile int b;
(void) a; /* line 5 */
(void) b; /* line 6 */
return 0;
}

I'd say yes to both. It's possible for type int to have trap
representations. If it does, and if ``a'' happens to hold a trap
representation, then the behavior of an attempt to access the value of
``a'' is undefined.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Barry Schwarz
Guest
Posts: n/a
 
      12-26-2009
On Sat, 26 Dec 2009 16:26:43 +0000 (UTC), Simon P Simonson
<(E-Mail Removed)> wrote:

>In the following code,
>
> 1 main()
> 2 {
> 3 auto a;
> 4 volatile b;
> 5 (void) a;
> 6 (void) b;
> 7 }
>
>is line 5 an undefined behavior? (I would say NO)
>
>is line 6 an undefined behavior? (I would say YES)


An uninitialized variable without static duration has an indeterminate
value. Any attempt to evaluate such a value leads to undefined
behavior. The fact that you discard the result of the evaluation is
irrelevant. Both statements invoke undefined behavior.

--
Remove del for email
 
Reply With Quote
 
Nobody
Guest
Posts: n/a
 
      12-29-2009
On Sat, 26 Dec 2009 16:26:43 +0000, Simon P Simonson wrote:

> In the following code,
>
> 1 main()
> 2 {
> 3 auto a;


What's with the "auto" qualifier?

In over 20 years of C programming, I haven't even seen it once in
real-world code.

It's primary purpose seems to be to trip up programmers who don't play
language lawyer as a hobby. I.e.:

Step 1: write:

int auto = 0; /* do "it" automatically */

Step 2: spend 5 minutes wondering why the compiler's complaining about
"syntax error before '=' token".

Step 3: discover that changing it to:

int xauto = 0; /* do "it" automatically */

eliminates the error message.

Step 4: ask the resident language lawyer about "auto".

Step 5: end up spending the rest of the afternoon discussing punched
cards, EBCDIC, and JCL.

 
Reply With Quote
 
Simon P Simonson
Guest
Posts: n/a
 
      12-30-2009
Barry Schwarz wrote:

> On Sat, 26 Dec 2009 16:26:43 +0000 (UTC), Simon P Simonson
> <(E-Mail Removed)> wrote:
>
>>In the following code,
>>
>> 1 main()
>> 2 {
>> 3 auto a;
>> 4 volatile b;
>> 5 (void) a;
>> 6 (void) b;
>> 7 }
>>
>>is line 5 an undefined behavior? (I would say NO)
>>
>>is line 6 an undefined behavior? (I would say YES)

>
> An uninitialized variable without static duration has an indeterminate
> value. Any attempt to evaluate such a value leads to undefined
> behavior. The fact that you discard the result of the evaluation is
> irrelevant. Both statements invoke undefined behavior.


Are you sure about this analysis?

Code 1 <<EOF
auto a;
(void) a;
EOF

Code 2 <<EOF
auto a;
EOF

By the "as if" rule, these two code extracts are equivalent, and most
(all?) compilers will not generate any code for Code 1 following the "as
if" rule.
 
Reply With Quote
 
Simon P Simonson
Guest
Posts: n/a
 
      12-30-2009
Nobody wrote:
> On Sat, 26 Dec 2009 16:26:43 +0000, Simon P Simonson wrote:
>
>> In the following code,
>>
>> 1 main()
>> 2 {
>> 3 auto a;

>
> What's with the "auto" qualifier?
>
> In over 20 years of C programming, I haven't even seen it once in
> real-world code.
>
> It's primary purpose seems to be to trip up programmers who don't play
> language lawyer as a hobby. I.e.:
>
> Step 1: write:
>
> int auto = 0; /* do "it" automatically */
>
> Step 2: spend 5 minutes wondering why the compiler's complaining about
> "syntax error before '=' token".
>
> Step 3: discover that changing it to:
>
> int xauto = 0; /* do "it" automatically */
>
> eliminates the error message.
>
> Step 4: ask the resident language lawyer about "auto".
>
> Step 5: end up spending the rest of the afternoon discussing punched
> cards, EBCDIC, and JCL.


Obviously I used auto to emphasize and draw attention to the contrast
between volatile and non-volatile variables that was at the heart of my
question. Normally I don't use the auto qualifier in my code.
 
Reply With Quote
 
Simon P Simonson
Guest
Posts: n/a
 
      12-30-2009
Simon P Simonson wrote:

> Barry Schwarz wrote:
>
>> On Sat, 26 Dec 2009 16:26:43 +0000 (UTC), Simon P Simonson
>> <(E-Mail Removed)> wrote:
>>
>>>In the following code,
>>>
>>> 1 main()
>>> 2 {
>>> 3 auto a;
>>> 4 volatile b;
>>> 5 (void) a;
>>> 6 (void) b;
>>> 7 }
>>>
>>>is line 5 an undefined behavior? (I would say NO)
>>>
>>>is line 6 an undefined behavior? (I would say YES)

>>
>> An uninitialized variable without static duration has an indeterminate
>> value. Any attempt to evaluate such a value leads to undefined
>> behavior. The fact that you discard the result of the evaluation is
>> irrelevant. Both statements invoke undefined behavior.

>
> Are you sure about this analysis?
>
> Code 1 <<EOF
> auto a;
> (void) a;
> EOF
>
> Code 2 <<EOF
> auto a;
> EOF
>
> By the "as if" rule, these two code extracts are equivalent, and most
> (all?) compilers will not generate any code for Code 1 following the "as
> if" rule.


Actually this raises the interesting question: What code should a
compiler generated for Code 3?

Code 3 <<EOF
volatile a;
(void) a;
EOF
 
Reply With Quote
 
Simon P Simonson
Guest
Posts: n/a
 
      12-30-2009
Simon P Simonson wrote:

> Nobody wrote:
>> On Sat, 26 Dec 2009 16:26:43 +0000, Simon P Simonson wrote:
>>
>>> In the following code,
>>>
>>> 1 main()
>>> 2 {
>>> 3 auto a;

>>
>> What's with the "auto" qualifier?
>>
>> In over 20 years of C programming, I haven't even seen it once in
>> real-world code.
>>
>> It's primary purpose seems to be to trip up programmers who don't play
>> language lawyer as a hobby. I.e.:
>>
>> Step 1: write:
>>
>> int auto = 0; /* do "it" automatically */
>>
>> Step 2: spend 5 minutes wondering why the compiler's complaining about
>> "syntax error before '=' token".
>>
>> Step 3: discover that changing it to:
>>
>> int xauto = 0; /* do "it" automatically */
>>
>> eliminates the error message.
>>
>> Step 4: ask the resident language lawyer about "auto".
>>
>> Step 5: end up spending the rest of the afternoon discussing punched
>> cards, EBCDIC, and JCL.

>
> Obviously I used auto to emphasize and draw attention to the contrast
> between volatile and non-volatile variables that was at the heart of my
> question. Normally I don't use the auto qualifier in my code.


This also raise the iteresting question: Is it a good idea to use
slightly obscure language features in your code (e.g. sizeof a++) to
force future maintainers of your code to be up to scratch on the dark
corners of the language?
 
Reply With Quote
 
Tom St Denis
Guest
Posts: n/a
 
      12-30-2009
On Dec 30, 8:33*am, Simon P Simonson <(E-Mail Removed)> wrote:
> Simon P Simonson wrote:
> > Nobody wrote:
> >> On Sat, 26 Dec 2009 16:26:43 +0000, Simon P Simonson wrote:

>
> >>> In the following code,

>
> >>> * * *1 * * main()
> >>> * * *2 * * {
> >>> * * *3 * * * auto a;

>
> >> What's with the "auto" qualifier?

>
> >> In over 20 years of C programming, I haven't even seen it once in
> >> real-world code.

>
> >> It's primary purpose seems to be to trip up programmers who don't play
> >> language lawyer as a hobby. I.e.:

>
> >> Step 1: write:

>
> >> * * * *int auto = 0; * /* do "it" automatically */

>
> >> Step 2: spend 5 minutes wondering why the compiler's complaining about
> >> "syntax error before '=' token".

>
> >> Step 3: discover that changing it to:

>
> >> * * * *int xauto = 0; */* do "it" automatically */

>
> >> eliminates the error message.

>
> >> Step 4: ask the resident language lawyer about "auto".

>
> >> Step 5: end up spending the rest of the afternoon discussing punched
> >> cards, EBCDIC, and JCL.

>
> > Obviously I used auto to emphasize and draw attention to the contrast
> > between volatile and non-volatile variables that was at the heart of my
> > question. Normally I don't use the auto qualifier in my code.

>
> This also raise the iteresting question: Is it a good idea to use
> slightly obscure language features in your code (e.g. sizeof a++) to
> force future maintainers of your code to be up to scratch on the dark
> corners of the language?


No, if I caught a developer here writing things like "sizeof a++" I'd
make them clean it up [or I'd do it myself and commit the fix].

Hard to read code is not the sign of genius. It's the sign of
lazyness. Using extra parenthesis for example may mean you're not
100% sure of order of precedence [bad] but it also makes the code a
lot easier to read [good].

Tom
 
Reply With Quote
 
Nick
Guest
Posts: n/a
 
      12-30-2009
Simon P Simonson <(E-Mail Removed)> writes:

> This also raise the iteresting question: Is it a good idea to use
> slightly obscure language features in your code (e.g. sizeof a++) to
> force future maintainers of your code to be up to scratch on the dark
> corners of the language?


Only if it's the "best" way to do things. Even if the future maintainer
is you, there's no point in making things complicated just for the fun
of it.

I feel that quite strongly about a number of the "is this undefined
behaviour" threads we get. If after 3 days people are still arguing
about it, just don't use it!
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ASP.NET won't retrieve query results that depend on union query Eric Nelson ASP .Net 5 02-04-2009 10:51 PM
Trying to query the Address table data of AdventureWorks database from Query Analyzer - need help! Learner ASP .Net 1 01-30-2006 08:58 PM
Build dynamic sql query for JSTL <sql:query> Anonymous Java 0 10-13-2005 10:01 PM
xpath query query David Gordon XML 2 05-18-2005 03:33 PM
CAML Query: Multiple Query Fields Issue Jon F. ASP .Net Web Services 0 05-12-2004 08:19 PM



Advertisments