Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Odd behavior with odd code

Reply
Thread Tools

Odd behavior with odd code

 
 
Michael Speer
Guest
Posts: n/a
 
      02-16-2007
#include <stdio.h>
#include <stdlib.h>

int main( int argc , char ** argv )
{
looper:
printf( "%d\n" , argc ) ;
printf( "%x\n" , &&looper ) ;
if( argc > 0 )
((int(*)(int,char**))&&looper)( 0 , argv ) ;
return 0 ;
}

Linux version 2.6.17-10-386 (root@vernadsky) (gcc version 4.1.2
20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)) #2 Fri Oct 13 18:41:40
UTC 2006 (Ubuntu 2.6.17-10.33-386)

gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)

On this box the code above compiles but runs in an infinite loop.
Instead of pushing the stack pointer and calling the label location as
a function with the arguments given as I expected, the compiler
instead acts as though it was a simple goto and reuses the original
arguments.

gdb backtrace sees only a single frame.

 
Reply With Quote
 
 
 
 
santosh
Guest
Posts: n/a
 
      02-16-2007
Michael Speer wrote:
> #include <stdio.h>
> #include <stdlib.h>
>
> int main( int argc , char ** argv )
> {
> looper:
> printf( "%d\n" , argc ) ;
> printf( "%x\n" , &&looper ) ;
> if( argc > 0 )
> ((int(*)(int,char**))&&looper)( 0 , argv ) ;
> return 0 ;
> }
>
> Linux version 2.6.17-10-386 (root@vernadsky) (gcc version 4.1.2
> 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)) #2 Fri Oct 13 18:41:40
> UTC 2006 (Ubuntu 2.6.17-10.33-386)
>
> gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
>
> On this box the code above compiles but runs in an infinite loop.
> Instead of pushing the stack pointer and calling the label location as
> a function with the arguments given as I expected, the compiler
> instead acts as though it was a simple goto and reuses the original
> arguments.
>
> gdb backtrace sees only a single frame.


This group discusses ISO C. Your code uses gcc specific extensions and
thus it's behaviour is outside the scope of this group. Maybe a gcc
mailing list or group would be more appropriate.

 
Reply With Quote
 
 
 
 
Walter Roberson
Guest
Posts: n/a
 
      02-16-2007
In article <(E-Mail Removed). com>,
Michael Speer <(E-Mail Removed)> wrote:

>#include <stdio.h>
>#include <stdlib.h>


You do not appear to be using anything from stdlib.h

>int main( int argc , char ** argv )
>{
> looper:
> printf( "%d\n" , argc ) ;
> printf( "%x\n" , &&looper ) ;


A label is not an object, and cannot have its address taken.
A label is not even in the same namespace as objects.

If you did manage to take the address of a label, then
a %x format would not be the correct format with which to print
out the address. You need %p to print out pointers.

> if( argc > 0 )
> ((int(*)(int,char**))&&looper)( 0 , argv ) ;
> return 0 ;
>}


>Linux version 2.6.17-10-386 (root@vernadsky) (gcc version 4.1.2
>20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)) #2 Fri Oct 13 18:41:40
>UTC 2006 (Ubuntu 2.6.17-10.33-386)
>
>gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
>
>On this box the code above compiles but runs in an infinite loop.


You didn't compile with C, you compiled with gcc. gcc implements
a C-like language, but does not implement C unless you use a
number of compile options to force it to compile the way a C compiler
should. For assistance with the C-like language implemented
by gcc, you would need to ask in a gcc newsgroup. (You won't be
able to compile your program as real C.)

>Instead of pushing the stack pointer and calling the label location as
>a function with the arguments given as I expected, the compiler
>instead acts as though it was a simple goto and reuses the original
>arguments.


Anything can happen when you violate C semantics.

--
Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson
 
Reply With Quote
 
Roberto Waltman
Guest
Posts: n/a
 
      02-16-2007
"Michael Speer" <(E-Mail Removed)> wrote:

>#include <stdio.h>
>#include <stdlib.h>
>
>int main( int argc , char ** argv )
>{
> looper:
> printf( "%d\n" , argc ) ;
> printf( "%x\n" , &&looper ) ;
> if( argc > 0 )
> ((int(*)(int,char**))&&looper)( 0 , argv ) ;
> return 0 ;
>}
>...
>
>On this box the code above compiles but runs in an infinite loop.
>Instead of pushing the stack pointer and calling the label location as
>a function with the arguments given as I expected, the compiler
>instead acts as though it was a simple goto and reuses the original
>arguments.


I don't understand what is the meaning of &&looper, "the address of
the address of a label?". A label is neither a function nor an object,
so the unary & can not be applied to it. It this program produced
"expected results" in some other system that is sheer luck. (Or lack
thereof)


From WG14/N1124 Committee Draft — May 6, 2005 ISO/IEC 9899:TC2

6.5.3.2 Address and indirection operators

Constraints

1 The operand of the unary & operator shall be either a function
designator, the result of a [] or unary * operator, or an lvalue that
designates an object that is not a bit-field and is not declared with
the register storage-class specifier.

2 The operand of the unary * operator shall have pointer type.

Semantics

3 The unary & operator yields the address of its operand. If the
operand has type ‘‘type’’, the result has type ‘‘pointer to type’’. If
the operand is the result of a unary * operator, neither that operator
nor the & operator is evaluated and the result is as if both were
omitted, except that the constraints on the operators still apply and
the result is not an lvalue. Similarly, if the operand is the result
of a [] operator, neither the & operator nor the unary * that is
implied by the [] is evaluated and the result is as if the & operator
were removed and the [] operator were changed to a + operator.
Otherwise, the result is a pointer to the object or function
designated by its operand.

Roberto Waltman

[ Please reply to the group,
return address is invalid ]
 
Reply With Quote
 
=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=
Guest
Posts: n/a
 
      02-16-2007
Roberto Waltman wrote:
> "Michael Speer" <(E-Mail Removed)> wrote:
>
> >#include <stdio.h>
> >#include <stdlib.h>
> >
> >int main( int argc , char ** argv )
> >{
> > looper:
> > printf( "%d\n" , argc ) ;
> > printf( "%x\n" , &&looper ) ;
> > if( argc > 0 )
> > ((int(*)(int,char**))&&looper)( 0 , argv ) ;
> > return 0 ;
> >}
> >...
> >
> >On this box the code above compiles but runs in an infinite loop.
> >Instead of pushing the stack pointer and calling the label location as
> >a function with the arguments given as I expected, the compiler
> >instead acts as though it was a simple goto and reuses the original
> >arguments.

>
> I don't understand what is the meaning of &&looper, "the address of
> the address of a label?". A label is neither a function nor an object,
> so the unary & can not be applied to it. It this program produced
> "expected results" in some other system that is sheer luck. (Or lack
> thereof)


It's not two instances of &, but it's one instance of &&, just like
how ++1 is invalid even though it would make sense if read as + + 1.
And the use of && as a unary operator applied to a label is a compiler
extension for which a diagnostic is correctly issued in conforming
mode.

 
Reply With Quote
 
Michael Speer
Guest
Posts: n/a
 
      02-16-2007

Santosh : I will not bother this group again with problems that
apparently do not extend to C but in.

Walter : on my system the sizeof( int ) == sizeof( pointer ) and
pointers are printed in hex so it printed the same, though I know it
is not guaranteed. Thank you for pointing out the appropriate %p
format symbol. Your insight of gcc implementing a C-like language
that deviates from the standard is also welcomed.

Roberto : I do not know why &&label takes the address of the label,
but it seems to do so readily. It is likely, judging from Santosh, a
gcc extension or a fluke. I got this informations from another thread
from which the explanation was absent.

Thank you for your comments.

 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      02-16-2007
Michael Speer wrote:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main( int argc , char ** argv )
> {
> looper:
> printf( "%d\n" , argc ) ;
> printf( "%x\n" , &&looper ) ;
> if( argc > 0 )
> ((int(*)(int,char**))&&looper)( 0 , argv ) ;
> return 0 ;
> }


Why this contortion? Why not simply:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char ** argv) {
printf( "%d\n" , argc ) ;
if(argc > 0) return main(0, argv)
return 0 ;
}

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews


 
Reply With Quote
 
Roberto Waltman
Guest
Posts: n/a
 
      02-16-2007
"Michael Speer" wrote:
>...
>Roberto : I do not know why &&label takes the address of the label,
>but it seems to do so readily. It is likely, judging from Santosh, a
>gcc extension or a fluke...


I learned something new: This is GCC extension.

From

http://gcc.gnu.org/onlinedocs/gcc-4....bels-as-Values

5.3 Labels as Values

You can get the address of a label defined in the
current function (or a containing function) with
the unary operator `&&' ...

Sorry, can not help with your original question...


Roberto Waltman

[ Please reply to the group,
return address is invalid ]
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      02-16-2007
Roberto Waltman <(E-Mail Removed)> writes:
> "Michael Speer" <(E-Mail Removed)> wrote:
>>#include <stdio.h>
>>#include <stdlib.h>
>>
>>int main( int argc , char ** argv )
>>{
>> looper:
>> printf( "%d\n" , argc ) ;
>> printf( "%x\n" , &&looper ) ;
>> if( argc > 0 )
>> ((int(*)(int,char**))&&looper)( 0 , argv ) ;
>> return 0 ;
>>}
>>...
>>
>>On this box the code above compiles but runs in an infinite loop.
>>Instead of pushing the stack pointer and calling the label location as
>>a function with the arguments given as I expected, the compiler
>>instead acts as though it was a simple goto and reuses the original
>>arguments.

>
> I don't understand what is the meaning of &&looper, "the address of
> the address of a label?". A label is neither a function nor an object,
> so the unary & can not be applied to it. It this program produced
> "expected results" in some other system that is sheer luck. (Or lack
> thereof)

[...]

That's actually the "&&" operator, a gcc extension that takes the
address of a label and yields a result of type void*.

Allowing conversion of a value of type void* to a pointer-to-function
type is also a gcc extension.

See the gcc documentation or gnu.gcc.help for more information.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
Roberto Waltman
Guest
Posts: n/a
 
      02-16-2007
Keith Thompson <(E-Mail Removed)> wrote:
>Roberto Waltman <(E-Mail Removed)> writes:
>>
>> I don't understand what is the meaning of &&looper, "the address of
>> the address of a label?"...

>
>That's actually the "&&" operator, a gcc extension that takes the
>address of a label and yields a result of type void*.
>...
>See the gcc documentation or gnu.gcc.help for more information.


Thanks, I already did. Harald van D?k and Michael Speer pointed in
that direction.
I have used gcc in several projects, but always as gcc -ansi -Wall
-pedantic -std= ...


Roberto Waltman

[ Please reply to the group,
return address is invalid ]
 
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
VERY odd routing behavior when attempting VPN connections over Wifi Robert Gordon Wireless Networking 0 08-25-2005 04:04 PM
Firefox under Linux -- odd behavior Dennis J. Tuchler Firefox 0 07-28-2004 04:05 PM
Step-thru code - odd behavior ASP .Net 2 06-01-2004 06:10 PM
Odd behavior behind the PIX Charles Haron Cisco 1 04-21-2004 04:05 AM
Odd console behavior on Cat 5005 Mike Voss Cisco 0 11-19-2003 10:49 PM



Advertisments