Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #10309 > unrolled thread

Reversing a linked list

Back to article view | Back to comp.lang.c

Contents

  Reversing a linked list jacob navia <jacob@spamsink.net> - 2011-09-16 08:30 +0200
    Re: Reversing a linked list jacob navia <jacob@spamsink.net> - 2011-09-16 08:33 +0200
    Re: Reversing a linked list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-16 12:51 +0100
      Re: Reversing a linked list jacob navia <jacob@spamsink.net> - 2011-09-16 14:18 +0200
        Re: Reversing a linked list jacob navia <jacob@spamsink.net> - 2011-09-16 14:26 +0200
          Re: Reversing a linked list Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-16 07:09 -0700
            Re: Reversing a linked list ImpalerCore <jadill33@gmail.com> - 2011-09-16 08:28 -0700
              Re: Reversing a linked list falk@rahul.net (Edward A. Falk) - 2011-09-16 16:34 +0000
              Re: Reversing a linked list Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-16 09:28 -0700
                Re: Reversing a linked list ImpalerCore <jadill33@gmail.com> - 2011-09-16 11:12 -0700
                  Re: Reversing a linked list "Tony" <nospamme@ever.net> - 2011-09-16 20:01 -0500
        Re: Reversing a linked list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-16 21:56 +0100
          Re: Reversing a linked list "Tony" <nospamme@ever.net> - 2011-09-16 20:16 -0500
            Re: Reversing a linked list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-17 02:48 +0100
              Re: Reversing a linked list "Tony" <nospamme@ever.net> - 2011-09-16 22:15 -0500
                Re: Reversing a linked list jacob navia <jacob@spamsink.net> - 2011-09-17 07:40 +0200
                  Re: Reversing a linked list "Tony" <nospamme@ever.net> - 2011-09-17 01:24 -0500
                  Re: Reversing a linked list cri@tiac.net (Richard Harter) - 2011-09-17 15:07 +0000
                    Re: Reversing a linked list jacob navia <jacob@spamsink.net> - 2011-09-17 17:47 +0200
                      Re: Reversing a linked list jacob navia <jacob@spamsink.net> - 2011-09-17 17:54 +0200
                    Re: Reversing a linked list Michael Press <rubrum@pacbell.net> - 2011-09-27 19:21 -0700
                Re: Reversing a linked list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-17 12:00 +0100
                  Re: Reversing a linked list "Tony" <nospamme@ever.net> - 2011-09-17 23:53 -0500
      Re: Reversing a linked list ImpalerCore <jadill33@gmail.com> - 2011-09-16 07:21 -0700
        Re: Reversing a linked list jacob navia <jacob@spamsink.net> - 2011-09-16 16:47 +0200
          Re: Reversing a linked list Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-16 08:20 -0700
          Re: Reversing a linked list "Tony" <nospamme@ever.net> - 2011-09-16 20:25 -0500
        Re: Reversing a linked list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-16 22:32 +0100
        Re: Reversing a linked list pete <pfiland@mindspring.com> - 2011-09-16 17:53 -0400
      Re: Reversing a linked list "Tony" <nospamme@ever.net> - 2011-09-16 19:48 -0500
        Re: Reversing a linked list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-17 02:41 +0100
          Re: Reversing a linked list "Tony" <nospamme@ever.net> - 2011-09-16 22:57 -0500
            Re: Reversing a linked list "BartC" <bc@freeuk.com> - 2011-09-17 12:48 +0100
              Re: Reversing a linked list jacob navia <jacob@spamsink.net> - 2011-09-17 13:55 +0200
              Re: Reversing a linked list "Tony" <nospamme@ever.net> - 2011-09-17 23:39 -0500
    Re: Reversing a linked list HENRY Eshbaugh <henryeshbaugh@gmail.com> - 2011-09-16 16:56 -0700
      Re: Reversing a linked list Ian Collins <ian-news@hotmail.com> - 2011-09-17 12:09 +1200
        Re: Reversing a linked list HENRY Eshbaugh <henryeshbaugh@gmail.com> - 2011-09-16 19:53 -0700
          Re: Reversing a linked list "Tony" <nospamme@ever.net> - 2011-09-16 23:00 -0500
            Re: Reversing a linked list Jonathan Leffler <jleffler@earthlink.net> - 2011-09-16 23:20 -0700
            Re: Reversing a linked list Keith Thompson <kst-u@mib.org> - 2011-09-17 13:46 -0700
              Re: Reversing a linked list henry eshbaugh <henryeshbaugh@gmail.com> - 2011-09-17 19:51 -0700
                Re: Reversing a linked list Keith Thompson <kst-u@mib.org> - 2011-09-18 01:28 -0700
                  Re: Reversing a linked list henry eshbaugh <henryeshbaugh@gmail.com> - 2011-09-18 15:39 -0700
                    Re: Reversing a linked list Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-18 22:43 +0000
                      Re: Reversing a linked list henry eshbaugh <henryeshbaugh@gmail.com> - 2011-09-18 17:54 -0700
                        Re: Reversing a linked list James Kuyper <jameskuyper@verizon.net> - 2011-09-18 21:20 -0400
                    Re: Reversing a linked list Keith Thompson <kst-u@mib.org> - 2011-09-18 17:30 -0700
                      Re: Reversing a linked list henry eshbaugh <henryeshbaugh@gmail.com> - 2011-09-18 17:51 -0700
                        Re: Reversing a linked list James Kuyper <jameskuyper@verizon.net> - 2011-09-18 21:34 -0400
                        Re: Reversing a linked list Robert Wessel <robertwessel2@yahoo.com> - 2011-09-18 21:25 -0500
                        Re: Reversing a linked list Keith Thompson <kst-u@mib.org> - 2011-09-19 09:56 -0700
                          Re: Reversing a linked list gazelle@shell.xmission.com (Kenny McCormack) - 2011-09-19 17:16 +0000
                          Re: Reversing a linked list Willem <willem@toad.stack.nl> - 2011-09-19 17:25 +0000
                            Re: Reversing a linked list Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-19 23:40 -0700
                            Re: Reversing a linked list henry eshbaugh <henryeshbaugh@gmail.com> - 2011-09-20 17:55 -0700
                          Re: Reversing a linked list henry eshbaugh <henryeshbaugh@gmail.com> - 2011-09-20 17:48 -0700
                            Re: Reversing a linked list Geoff <geoff@invalid.invalid> - 2011-09-20 19:12 -0700
                              Re: Reversing a linked list henry eshbaugh <henryeshbaugh@gmail.com> - 2011-09-21 10:15 -0700
                                Re: Reversing a linked list David Resnick <lndresnick@gmail.com> - 2011-09-22 08:43 -0700
                                  Re: Reversing a linked list Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-23 02:45 -0700
                                    Re: Reversing a linked list David Resnick <lndresnick@gmail.com> - 2011-09-23 05:38 -0700
                                      Re: Reversing a linked list Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-23 07:58 -0700
                                        Re: Reversing a linked list David Resnick <lndresnick@gmail.com> - 2011-09-23 08:15 -0700
                                          Re: Reversing a linked list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-23 18:00 +0100
                                            Re: Reversing a linked list David Resnick <lndresnick@gmail.com> - 2011-09-23 10:49 -0700
                                              Re: Reversing a linked list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-23 20:05 +0100
                                            Re: Reversing a linked list pete <pfiland@mindspring.com> - 2011-09-23 18:05 -0400
                                              Re: Reversing a linked list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-24 00:19 +0100
                                        Re: Reversing a linked list ImpalerCore <jadill33@gmail.com> - 2011-09-23 09:25 -0700
                                Re: Reversing a linked list Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-22 22:49 +0300
                            Re: Reversing a linked list Keith Thompson <kst-u@mib.org> - 2011-09-20 19:51 -0700
                              Re: Reversing a linked list henry eshbaugh <henryeshbaugh@gmail.com> - 2011-09-21 09:51 -0700
                                Re: Reversing a linked list Keith Thompson <kst-u@mib.org> - 2011-09-21 11:21 -0700
                            Re: Reversing a linked list James Kuyper <jameskuyper@verizon.net> - 2011-09-20 23:00 -0400
                              Re: Reversing a linked list henry eshbaugh <henryeshbaugh@gmail.com> - 2011-09-21 09:47 -0700
                                Re: Reversing a linked list Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-23 11:22 +0300
                                  Re: Reversing a linked list Keith Thompson <kst-u@mib.org> - 2011-09-23 08:20 -0700
                                    Re: Reversing a linked list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-23 18:12 +0100
                                      Re: Reversing a linked list Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 13:13 -0800
                                    Re: Reversing a linked list Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-23 23:49 +0300
                                      Re: Reversing a linked list James Kuyper <jameskuyper@verizon.net> - 2011-09-24 08:15 -0400
                                        Re: Reversing a linked list Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-24 20:15 +0300
                                      Re: Reversing a linked list Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 13:28 -0800
                                        Re: Reversing a linked list Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-12 01:41 +0200
                                          Re: Reversing a linked list Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-08 09:08 -0800
                                            Re: Reversing a linked list Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-03-13 17:21 +0200
                              Re: Reversing a linked list Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 13:04 -0800
                            Re: Reversing a linked list Seebs <usenet-nospam@seebs.net> - 2011-09-23 01:46 +0000
                    Re: Reversing a linked list James Kuyper <jameskuyper@verizon.net> - 2011-09-18 21:17 -0400
              Re: Reversing a linked list "Tony" <nospamme@ever.net> - 2011-09-17 23:50 -0500
                Re: Reversing a linked list Keith Thompson <kst-u@mib.org> - 2011-09-18 01:29 -0700
          Re: Reversing a linked list Seebs <usenet-nospam@seebs.net> - 2011-09-18 07:03 +0000
      Re: Reversing a linked list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-17 02:13 +0100
        Re: Reversing a linked list HENRY Eshbaugh <henryeshbaugh@gmail.com> - 2011-09-16 19:52 -0700
          Re: Reversing a linked list Willem <willem@toad.stack.nl> - 2011-09-17 08:58 +0000
            Re: Reversing a linked list henry eshbaugh <henryeshbaugh@gmail.com> - 2011-09-18 15:32 -0700
              Re: Reversing a linked list James Kuyper <jameskuyper@verizon.net> - 2011-09-18 21:36 -0400
                Re: Reversing a linked list cri@tiac.net (Richard Harter) - 2011-09-19 05:24 +0000
                  Re: Reversing a linked list James Kuyper <jameskuyper@verizon.net> - 2011-09-19 08:21 -0400
                    Re: Reversing a linked list cri@tiac.net (Richard Harter) - 2011-09-19 14:28 +0000
                      Re: Reversing a linked list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-19 17:01 +0100
                        Re: Reversing a linked list cri@tiac.net (Richard Harter) - 2011-09-19 16:25 +0000
                  Re: Reversing a linked list henry eshbaugh <henryeshbaugh@gmail.com> - 2011-09-21 10:41 -0700
                    Re: Reversing a linked list Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-21 17:58 +0000
                    Re: Reversing a linked list James Kuyper <jameskuyper@verizon.net> - 2011-09-21 14:07 -0400
                    Re: Reversing a linked list Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-21 11:15 -0700
                      Re: Reversing a linked list Keith Thompson <kst-u@mib.org> - 2011-09-21 11:37 -0700
                        Re: Reversing a linked list Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-23 11:50 +0300
                    Re: Reversing a linked list Seebs <usenet-nospam@seebs.net> - 2011-09-23 01:46 +0000
      Re: Reversing a linked list Geoff <geoff@invalid.invalid> - 2011-09-18 18:22 -0700
    Re: Reversing a linked list "Tony" <nospamme@ever.net> - 2011-09-16 19:37 -0500
      Re: Reversing a linked list jacob navia <jacob@spamsink.net> - 2011-09-17 07:52 +0200
        Re: Reversing a linked list "Tony" <nospamme@ever.net> - 2011-09-17 02:09 -0500
          Re: Reversing a linked list Ian Collins <ian-news@hotmail.com> - 2011-09-17 19:35 +1200
            Re: Reversing a linked list "Tony" <nospamme@ever.net> - 2011-09-17 03:35 -0500
          Programming languages jacob navia <jacob@spamsink.net> - 2011-09-17 22:14 +0200
            Re: Programming languages "Tony" <nospamme@ever.net> - 2011-09-18 00:11 -0500
              Re: Programming languages jacob navia <jacob@spamsink.net> - 2011-09-18 08:37 +0200
              Re: Programming languages Seebs <usenet-nospam@seebs.net> - 2011-09-18 07:03 +0000
                Re: Programming languages jacob navia <jacob@spamsink.net> - 2011-09-18 09:50 +0200
                Re: Programming languages Keith Thompson <kst-u@mib.org> - 2011-09-18 01:31 -0700
                  Re: Programming languages James Kuyper <jameskuyper@verizon.net> - 2011-09-18 06:43 -0400
                    Re: Programming languages Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-18 07:42 -0700
                  Re: Programming languages "Tony" <nospamme@ever.net> - 2011-09-18 04:05 -0500
              Re: Programming languages Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-18 07:40 -0700
    Re: Reversing a linked list Gene <gene.ressler@gmail.com> - 2011-09-22 06:59 -0700

Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7  Next page →

#10409

"Tony" <nospamme@ever.net> writes:
> HENRY Eshbaugh wrote:
>> On Sep 16, 8:09 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>>> You shouldn't use names starting with a double underscore, they are
>>> reserved for the implementation.
>>
>> If that's not the implementation of the algorithm, then what is it?
>
> By "implementation", Ian meant "the compiler". That is what is typically 
> understood as "the implementation". As in, "the implementation of the 
> language".

The "implementation" includes the compiler, the standard library, the
linker, and probably some other things.

> (Aside: Isn't a single underscore suggested for use by libraries?). 

The simple rule is to avoid defining *any* identifier starting with an
identifier, unless you're writing a C implementation.

It's not quite that simple.  Identifiers starting with two underscores,
or with an underscore followed by an upper case letter, are reserved for
all purposes.  Identifiers starting with an underscore *not* followed by
another underscore or by an upper case letter are reserved in fewer
contexts.  So you *can* use such identifiers in your own code, but it's
easier not to.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#10420

On Sep 17, 4:46 pm, Keith Thompson <ks...@mib.org> wrote:
> "Tony" <nospa...@ever.net> writes:
> > HENRY Eshbaugh wrote:
> >> On Sep 16, 8:09 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> >>> You shouldn't use names starting with a double underscore, they are
> >>> reserved for the implementation.
>
> >> If that's not the implementation of the algorithm, then what is it?
>
> > By "implementation", Ian meant "the compiler". That is what is typically
> > understood as "the implementation". As in, "the implementation of the
> > language".
>
> The "implementation" includes the compiler, the standard library, the
> linker, and probably some other things.
>
> > (Aside: Isn't a single underscore suggested for use by libraries?).
>
> The simple rule is to avoid defining *any* identifier starting with an
> identifier, unless you're writing a C implementation.
>
> It's not quite that simple.  Identifiers starting with two underscores,
> or with an underscore followed by an upper case letter, are reserved for
> all purposes.  Identifiers starting with an underscore *not* followed by
> another underscore or by an upper case letter are reserved in fewer
> contexts.  So you *can* use such identifiers in your own code, but it's
> easier not to.
>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org  <http://www.ghoti.net/~kst>
> "We must do something.  This is something.  Therefore, we must do this."
>     -- Antony Jay and Jonathan Lynn, "Yes Minister"

K.

With my compiler, symbols are _[name]. So, it comes out to be
___reverse_list(), which isn't too bad.

But it's a coding style issue anyway, and is trivial.

[toc] | [prev] | [next] | [standalone]

#10430

henry eshbaugh <henryeshbaugh@gmail.com> writes:
> On Sep 17, 4:46 pm, Keith Thompson <ks...@mib.org> wrote:
>> "Tony" <nospa...@ever.net> writes:
>> > HENRY Eshbaugh wrote:
>> >> On Sep 16, 8:09 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>> >>> You shouldn't use names starting with a double underscore, they are
>> >>> reserved for the implementation.
>>
>> >> If that's not the implementation of the algorithm, then what is it?
>>
>> > By "implementation", Ian meant "the compiler". That is what is typically
>> > understood as "the implementation". As in, "the implementation of the
>> > language".
>>
>> The "implementation" includes the compiler, the standard library, the
>> linker, and probably some other things.
>>
>> > (Aside: Isn't a single underscore suggested for use by libraries?).
>>
>> The simple rule is to avoid defining *any* identifier starting with an
>> identifier, unless you're writing a C implementation.
>>
>> It's not quite that simple.  Identifiers starting with two underscores,
>> or with an underscore followed by an upper case letter, are reserved for
>> all purposes.  Identifiers starting with an underscore *not* followed by
>> another underscore or by an upper case letter are reserved in fewer
>> contexts.  So you *can* use such identifiers in your own code, but it's
>> easier not to.
[...]
>
> With my compiler, symbols are _[name]. So, it comes out to be
> ___reverse_list(), which isn't too bad.

What do you mean, it "isn't too bad"?

> But it's a coding style issue anyway, and is trivial.

It's not merely coding style.  The identifier "__reverse_list" is
reserved to the implementation.  Using it in your own code makes your
program's behavior undefined.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#10450

On Sep 18, 4:28 am, Keith Thompson <ks...@mib.org> wrote:
> What do you mean, it "isn't too bad"?

It's not unreadable. Sorry for not being clear.

> It's not merely coding style.  The identifier "__reverse_list" is
> reserved to the implementation.  Using it in your own code makes your
> program's behavior undefined.

Nope. Here's an example C program:


void __foo(void)
{
	return;
}

int main()
{
	___foo();
	return 0;
}

And here's the assembly generated by GCC:
	.text
.globl ___foo
___foo:
LFB2:
	pushq	%rbp
LCFI0:
	movq	%rsp, %rbp
LCFI1:
	leave
	ret
LFE2:
.globl _main
_main:
LFB3:
	pushq	%rbp
LCFI2:
	movq	%rsp, %rbp
LCFI3:
	movl	$0, %eax
	call	____foo
	movl	$0, %eax
	leave
	ret
LFE3:
	.section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms
+live_support
EH_frame1:
	.set L$set$0,LECIE1-LSCIE1
	.long L$set$0
LSCIE1:
	.long	0x0
	.byte	0x1
	.ascii "zR\0"
	.byte	0x1
	.byte	0x78
	.byte	0x10
	.byte	0x1
	.byte	0x10
	.byte	0xc
	.byte	0x7
	.byte	0x8
	.byte	0x90
	.byte	0x1
	.align 3
LECIE1:
.globl ___foo.eh
___foo.eh:
LSFDE1:
	.set L$set$1,LEFDE1-LASFDE1
	.long L$set$1
LASFDE1:
	.long	LASFDE1-EH_frame1
	.quad	LFB2-.
	.set L$set$2,LFE2-LFB2
	.quad L$set$2
	.byte	0x0
	.byte	0x4
	.set L$set$3,LCFI0-LFB2
	.long L$set$3
	.byte	0xe
	.byte	0x10
	.byte	0x86
	.byte	0x2
	.byte	0x4
	.set L$set$4,LCFI1-LCFI0
	.long L$set$4
	.byte	0xd
	.byte	0x6
	.align 3
LEFDE1:
.globl _main.eh
_main.eh:
LSFDE3:
	.set L$set$5,LEFDE3-LASFDE3
	.long L$set$5
LASFDE3:
	.long	LASFDE3-EH_frame1
	.quad	LFB3-.
	.set L$set$6,LFE3-LFB3
	.quad L$set$6
	.byte	0x0
	.byte	0x4
	.set L$set$7,LCFI2-LFB3
	.long L$set$7
	.byte	0xe
	.byte	0x10
	.byte	0x86
	.byte	0x2
	.byte	0x4
	.set L$set$8,LCFI3-LCFI2
	.long L$set$8
	.byte	0xd
	.byte	0x6
	.align 3
LEFDE3:
	.subsections_via_symbols


Note ".globl ___foo". Like I said, GCC generates assembly with
identifiers _[name], so you can prefix names with "__." So, again,
it's largely a coding style issue.

[toc] | [prev] | [next] | [standalone]

#10452

On Sun, 18 Sep 2011 15:39:01 -0700, henry eshbaugh wrote:

> On Sep 18, 4:28 am, Keith Thompson <ks...@mib.org> wrote:
>> What do you mean, it "isn't too bad"?
> 
> It's not unreadable. Sorry for not being clear.
> 
>> It's not merely coding style.  The identifier "__reverse_list" is
>> reserved to the implementation.  Using it in your own code makes your
>> program's behavior undefined.
> 
> Nope. Here's an example C program:
> 
> 
> void __foo(void)
> {
> 	return;
> }
> 
> int main()
> {
> 	___foo();
> 	return 0;
> }
> 
> And here's the assembly generated by GCC:
> 	.text
> .globl ___foo
> ___foo:
> LFB2:
> 	pushq	%rbp
> LCFI0:
> 	movq	%rsp, %rbp
> LCFI1:
> 	leave
> 	ret
> LFE2:
> .globl _main
> _main:
> LFB3:
> 	pushq	%rbp
> LCFI2:
> 	movq	%rsp, %rbp
> LCFI3:
> 	movl	$0, %eax
> 	call	____foo
> 	movl	$0, %eax
> 	leave
> 	ret
> LFE3:
> 	.section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms
> +live_support
> EH_frame1:
> 	.set L$set$0,LECIE1-LSCIE1
> 	.long L$set$0
> LSCIE1:
> 	.long	0x0
> 	.byte	0x1
> 	.ascii "zR\0"
> 	.byte	0x1
> 	.byte	0x78
> 	.byte	0x10
> 	.byte	0x1
> 	.byte	0x10
> 	.byte	0xc
> 	.byte	0x7
> 	.byte	0x8
> 	.byte	0x90
> 	.byte	0x1
> 	.align 3
> LECIE1:
> .globl ___foo.eh
> ___foo.eh:
> LSFDE1:
> 	.set L$set$1,LEFDE1-LASFDE1
> 	.long L$set$1
> LASFDE1:
> 	.long	LASFDE1-EH_frame1
> 	.quad	LFB2-.
> 	.set L$set$2,LFE2-LFB2
> 	.quad L$set$2
> 	.byte	0x0
> 	.byte	0x4
> 	.set L$set$3,LCFI0-LFB2
> 	.long L$set$3
> 	.byte	0xe
> 	.byte	0x10
> 	.byte	0x86
> 	.byte	0x2
> 	.byte	0x4
> 	.set L$set$4,LCFI1-LCFI0
> 	.long L$set$4
> 	.byte	0xd
> 	.byte	0x6
> 	.align 3
> LEFDE1:
> .globl _main.eh
> _main.eh:
> LSFDE3:
> 	.set L$set$5,LEFDE3-LASFDE3
> 	.long L$set$5
> LASFDE3:
> 	.long	LASFDE3-EH_frame1
> 	.quad	LFB3-.
> 	.set L$set$6,LFE3-LFB3
> 	.quad L$set$6
> 	.byte	0x0
> 	.byte	0x4
> 	.set L$set$7,LCFI2-LFB3
> 	.long L$set$7
> 	.byte	0xe
> 	.byte	0x10
> 	.byte	0x86
> 	.byte	0x2
> 	.byte	0x4
> 	.set L$set$8,LCFI3-LCFI2
> 	.long L$set$8
> 	.byte	0xd
> 	.byte	0x6
> 	.align 3
> LEFDE3:
> 	.subsections_via_symbols
> 
> 
> Note ".globl ___foo". Like I said, GCC generates assembly with
> identifiers _[name], so you can prefix names with "__." So, again, it's
> largely a coding style issue.

Nope. It's a question of namespaces and the fact that your compiler/libs
may use '__foo' for some other purpose. Besides, empirical arguments aren't
the way to go debating standards.

-------------------------------------------------------------------------------
 ______________________________________
/ I hope I bought the right relish ... \
\ zzzzzzzzz ...                        /
 --------------------------------------
  \
   \
       ___  
     {~._.~}
      ( Y )
     ()~*~()   
     (_)-(_)   
-------------------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#10461

On Sep 18, 6:43 pm, Kleuskes & Moos <kleu...@somewhere.else.net>
wrote:
> Nope. It's a question of namespaces and the fact that your compiler/libs
> may use '__foo' for some other purpose. Besides, empirical arguments aren't
> the way to go debating standards.

My compiler and libraries don't. But if you can find any that do
reserve it, please let me know.

But compilers don't chop off pieces of the symbol to add underscores;
I don't see where you get the idea that they do.

[toc] | [prev] | [next] | [standalone]

#10463

On 09/18/2011 08:54 PM, henry eshbaugh wrote:
> On Sep 18, 6:43�pm, Kleuskes & Moos <kleu...@somewhere.else.net>
> wrote:
>> Nope. It's a question of namespaces and the fact that your compiler/libs
>> may use '__foo' for some other purpose. Besides, empirical arguments aren't
>> the way to go debating standards.
> 
> My compiler and libraries don't. But if you can find any that do
> reserve it, please let me know.

It's not the compiler that reserves those symbols, nor the libraries;
they merely use the reservation that's already been made. It's the C
standard that reserved those symbols.

> But compilers don't chop off pieces of the symbol to add underscores;
> I don't see where you get the idea that they do.

He expressed no such idea.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#10458

henry eshbaugh <henryeshbaugh@gmail.com> writes:
> On Sep 18, 4:28 am, Keith Thompson <ks...@mib.org> wrote:
>> What do you mean, it "isn't too bad"?
>
> It's not unreadable. Sorry for not being clear.
>
>> It's not merely coding style.  The identifier "__reverse_list" is
>> reserved to the implementation.  Using it in your own code makes your
>> program's behavior undefined.
>
> Nope.

Yup.

>       Here's an example C program:
>
>
> void __foo(void)
> {
> 	return;
> }
>
> int main()
> {
> 	___foo();
> 	return 0;
> }

You define your function as "__foo" and call it as "___foo()".  Was that
a typo?

> And here's the assembly generated by GCC:
[96 lines deleted]
>
>
> Note ".globl ___foo". Like I said, GCC generates assembly with
> identifiers _[name], so you can prefix names with "__." So, again,
> it's largely a coding style issue.

I never said it wouldn't work with whatever implementation you
happen to be using.  I didn't even say it would fail under *any*
implementation.  I said that the behavior is undefined.

Identifiers starting with "__" are reserved to the implementation.
If you define such an identifier yourself, your code's behavior
is undefined.  Among the infinitely many possible manifestations
of undefined behavior is that your code behaves just as you intend
it to.  Another possibility is that your implementation has chosen
to use the name "__foo" for its own purposes, and that attempting
to use it yourself causes a conflict.

By not defining your own identifiers starting with an underscore,
you remove that risk.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#10460

On Sep 18, 8:30 pm, Keith Thompson <ks...@mib.org> wrote:
> henry eshbaugh <henryeshba...@gmail.com> writes:
> > On Sep 18, 4:28 am, Keith Thompson <ks...@mib.org> wrote:
> >> What do you mean, it "isn't too bad"?
>
> > It's not unreadable. Sorry for not being clear.
>
> >> It's not merely coding style.  The identifier "__reverse_list" is
> >> reserved to the implementation.  Using it in your own code makes your
> >> program's behavior undefined.
>
> > Nope.
>
> Yup.
>
> >       Here's an example C program:
>
> > void __foo(void)
> > {
> >    return;
> > }
>
> > int main()
> > {
> >    ___foo();
> >    return 0;
> > }
>
> You define your function as "__foo" and call it as "___foo()".  Was that
> a typo?
  Yup.


> > And here's the assembly generated by GCC:
> [96 lines deleted]
>
> > Note ".globl ___foo". Like I said, GCC generates assembly with
> > identifiers _[name], so you can prefix names with "__." So, again,
> > it's largely a coding style issue.
>
> I never said it wouldn't work with whatever implementation you
> happen to be using.  I didn't even say it would fail under *any*
> implementation.  I said that the behavior is undefined.

Technically, the entire compilation process is undefined. :P.

I can't afford any compilers that aren't free, but be my guest to test
it out and let me know if there are compilers that do that.

I don't see why; it would break a lot of code and be overall pretty
pointless.

[toc] | [prev] | [next] | [standalone]

#10465

On 09/18/2011 08:51 PM, henry eshbaugh wrote:
> On Sep 18, 8:30�pm, Keith Thompson <ks...@mib.org> wrote:
...
>> I never said it wouldn't work with whatever implementation you
>> happen to be using. �I didn't even say it would fail under *any*
>> implementation. �I said that the behavior is undefined.
> 
> Technically, the entire compilation process is undefined. :P.

Not as far as the C standard is concerned. The C standard says that
"undefined behavior" is behavior "for which this international standard
imposes no requirements". That standard imposes LOTs of requirements on
the translation process as a whole (which corresponds to the combination
of compilation of linking).

> I can't afford any compilers that aren't free, but be my guest to test
> it out and let me know if there are compilers that do that.

There's no need for testing; read and understand the reservations
established by the C standard - make sure to never violate them, and you
code will (if it contains no other problems) work as specified by that
standard when translated and executed by a standard-conforming
implementation of C.

Ignore those reservations, and your code might or might not mysteriously
malfunction. If you want to take that risk, feel free to do so, but why
would you want to? What benefit do you gain? Do you get a thrill from
breaking the rules?

> I don't see why; it would break a lot of code and be overall pretty
> pointless.

The point is to give implementations of C a set of identifiers that they
are free to use without breaking your code, and to give you a set of
identifiers that you are free to use without breaking the
implementation. It serves essentially the same purpose as the dividers
on the highway that prevent traffic heading south from running into
traffic heading north; if you cross those dividers, you might be
perfectly safe, or you might cause a high-speed front-end collision.
Your chances of survival are a lot higher using reserved words in C than
crossing to the wrong side of a highway - but the risks are nonetheless
perfectly real.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#10467

On Sun, 18 Sep 2011 17:51:24 -0700 (PDT), henry eshbaugh
<henryeshbaugh@gmail.com> wrote:

>On Sep 18, 8:30 pm, Keith Thompson <ks...@mib.org> wrote:
>> henry eshbaugh <henryeshba...@gmail.com> writes:
>> > On Sep 18, 4:28 am, Keith Thompson <ks...@mib.org> wrote:
>> >> What do you mean, it "isn't too bad"?
>>
>> > It's not unreadable. Sorry for not being clear.
>>
>> >> It's not merely coding style.  The identifier "__reverse_list" is
>> >> reserved to the implementation.  Using it in your own code makes your
>> >> program's behavior undefined.
>>
>> > Nope.
>>
>> Yup.
>>
>> >       Here's an example C program:
>>
>> > void __foo(void)
>> > {
>> >    return;
>> > }
>>
>> > int main()
>> > {
>> >    ___foo();
>> >    return 0;
>> > }
>>
>> You define your function as "__foo" and call it as "___foo()".  Was that
>> a typo?
>  Yup.
>
>
>> > And here's the assembly generated by GCC:
>> [96 lines deleted]
>>
>> > Note ".globl ___foo". Like I said, GCC generates assembly with
>> > identifiers _[name], so you can prefix names with "__." So, again,
>> > it's largely a coding style issue.
>>
>> I never said it wouldn't work with whatever implementation you
>> happen to be using.  I didn't even say it would fail under *any*
>> implementation.  I said that the behavior is undefined.
>
>Technically, the entire compilation process is undefined. :P.
>
>I can't afford any compilers that aren't free, but be my guest to test
>it out and let me know if there are compilers that do that.
>
>I don't see why; it would break a lot of code and be overall pretty
>pointless.


The point is that names starting with double underscores are reserved
to the implementation - and many, perhaps most, or even all,
implementations do use names in that namespace for their own purposes.

I just looked at a link map for a modest sized module compiled with
MSVC, and I found: __threadid, __threadhandle, __gmtotime_t,
__doserrno, __onexitend, __onexitbegin, __mb_cur_max, __argc, __argv,
__tlsindex, __nullstring, __wnullstring, __lookuptable, __xc_a,
__xc_z, __xi_a, __xi_z, __xp_a, __xp_z, __xt_a, __xt_z, which are used
for various functions by the implementation.  If you defined any of
those, the program might not compile, or it might fail in unusual.
ways when run.

The fact that the list does not (at least for that one program)
include __foo, is immaterial - those names are reserved, and using
them cause your program's behavior to be undefined.  Which, as has
been pointed out, includes the possibility of doing what you intended,
although that might change with the next patch level of the compiler,
or on alternate Tuesdays, when the compiler feels like using __foo for
some reason, or with a different set of compiler flags.

Those names (along with some others), are not for you.  Don't use
them.

[toc] | [prev] | [next] | [standalone]

#10504

henry eshbaugh <henryeshbaugh@gmail.com> writes:
> On Sep 18, 8:30 pm, Keith Thompson <ks...@mib.org> wrote:
>> henry eshbaugh <henryeshba...@gmail.com> writes:
[...]
>> >       Here's an example C program:
>>
>> > void __foo(void)
>> > {
>> >    return;
>> > }
>>
>> > int main()
>> > {
>> >    ___foo();
>> >    return 0;
>> > }
>>
>> You define your function as "__foo" and call it as "___foo()".  Was that
>> a typo?
>   Yup.
[...]
>> >                                                         So, again,
>> > it's largely a coding style issue.
>>
>> I never said it wouldn't work with whatever implementation you
>> happen to be using.  I didn't even say it would fail under *any*
>> implementation.  I said that the behavior is undefined.
>
> Technically, the entire compilation process is undefined. :P.

So what?

The specific compilation process is not defined by the language
standard.  The language itself is.  That's why the language standard
exists.

> I can't afford any compilers that aren't free, but be my guest to test
> it out and let me know if there are compilers that do that.
>
> I don't see why; it would break a lot of code and be overall pretty
> pointless.

The only code it would break is already broken.

It's completely pointless to use identifiers starting with "__".
By doing so, you risk colliding with identifiers used by the
implementation.  By using identifiers that start with letters,
you avoid that risk -- at no cost.

I don't *care* whether any compilers use the name "__foo" internally,
because I don't define reserved identifiers in my own code.

Exactly what benefit do you get by calling your own function "__foo"
(rather than, say, "foo__")?

You have a choice between writing code with well defined behavior and
writing code with undefined behavior.  Why do you chose the latter?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#10507

In article <lnvcso5v3b.fsf@nuthaus.mib.org>,
Keith Thompson  <kst-u@mib.org> wrote:
...
>You have a choice between writing code with well defined behavior and
>writing code with undefined behavior.  Why do you chose the latter?

Speaking for the OP:

	Just to piss you off!

And it works!

-- 
Just for a change of pace, this sig is *not* an obscure reference to
comp.lang.c...

[toc] | [prev] | [next] | [standalone]

#10508

Keith Thompson wrote:
) Exactly what benefit do you get by calling your own function "__foo"
) (rather than, say, "foo__")?
)
) You have a choice between writing code with well defined behavior and
) writing code with undefined behavior.  Why do you chose the latter?

The most benign reason I can think of is that he's used to another language
where starting with underscores signifies that that function is not to be
used by other modules (usually when the language doesn't know the concept
of 'static functions').  Like Perl, for example.

Although they usually use a single underscore, not a double one.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#10553

On Sep 19, 8:25 pm, Willem <wil...@toad.stack.nl> wrote:
>
> The most benign reason I can think of is that he's used to another language
> where starting with underscores signifies that that function is not to be
> used by other modules (usually when the language doesn't know the concept
> of 'static functions').  Like Perl, for example.
>
I don't see an important difference between

/* call only in this file */
static int foo();

and

/* restricted to this module in another language */
function _foo[]

--
Lots of C programming goodies
http://www.malcolmmclean.site11.com/www

[toc] | [prev] | [next] | [standalone]

#10620

On Sep 19, 1:25 pm, Willem <wil...@toad.stack.nl> wrote:
> Keith Thompson wrote:
>
> ) Exactly what benefit do you get by calling your own function "__foo"
> ) (rather than, say, "foo__")?
> )
> ) You have a choice between writing code with well defined behavior and
> ) writing code with undefined behavior.  Why do you chose the latter?
>
> The most benign reason I can think of is that he's used to another language
> where starting with underscores signifies that that function is not to be
> used by other modules (usually when the language doesn't know the concept
> of 'static functions').  Like Perl, for example.
>
> Although they usually use a single underscore, not a double one.
>
> SaSW, Willem
> --
> Disclaimer: I am in no way responsible for any of the statements
>             made in the above text. For all I know I might be
>             drugged or something..
>             No I'm not paranoid. You all think I'm paranoid, don't you !
> #EOT

Actually, my first language was Python, but I've spent most of my time
programming working in C.

[toc] | [prev] | [next] | [standalone]

#10622

On Sep 19, 12:56 pm, Keith Thompson <ks...@mib.org> wrote:
> The only code it would break is already broken.
>
> It's completely pointless to use identifiers starting with "__".
> By doing so, you risk colliding with identifiers used by the
> implementation.  By using identifiers that start with letters,
> you avoid that risk -- at no cost.
>
> I don't *care* whether any compilers use the name "__foo" internally,
> because I don't define reserved identifiers in my own code.
>
> Exactly what benefit do you get by calling your own function "__foo"
> (rather than, say, "foo__")?
>
> You have a choice between writing code with well defined behavior and
> writing code with undefined behavior.  Why do you chose the latter?

It's a coding style issue. I use them for internal functions.

And it's not just me. You know who else happens to do that? The small
army of Linux kernel programmers. Have you ever read the source? It's
full of __init functions, __exit functions, __deprecated logic, and
__[name] all over the bloody place. Take, for example (from the root
of the kernel tree) drivers/xen/xenbus/xenbus_probe.c (copied and
pasted from grep):


./xen/xenbus/xenbus_probe.c:	__ATTR_RO(nodename),
./xen/xenbus/xenbus_probe.c:	__ATTR_RO(devtype),
./xen/xenbus/xenbus_probe.c:	__ATTR_RO(modalias),
./xen/xenbus/xenbus_probe.c:	__ATTR_NULL

or xenbus_client.c:


./xen/xenbus/xenbus_client.c:	path = kvasprintf(GFP_NOIO | __GFP_HIGH,
pathfmt, ap);
./xen/xenbus/xenbus_client.c:__xenbus_switch_state(struct
xenbus_device *dev,
./xen/xenbus/xenbus_client.c:	return __xenbus_switch_state(dev, state,
0);

drivers/xen/xen-pciback/vpci.c:
./xen/xen-pciback/vpci.c:	.init		= __xen_pcibk_init_devices,
./xen/xen-pciback/vpci.c:	.free		= __xen_pcibk_release_devices,
./xen/xen-pciback/vpci.c:	.find		= __xen_pcibk_get_pcifront_dev,
./xen/xen-pciback/vpci.c:	.publish	= __xen_pcibk_publish_pci_roots,
./xen/xen-pciback/vpci.c:	.release	= __xen_pcibk_release_pci_dev,
./xen/xen-pciback/vpci.c:	.add		= __xen_pcibk_add_pci_dev,
./xen/xen-pciback/vpci.c:	.get		= __xen_pcibk_get_pci_dev,

drivers/xen/xen-pciback/pci_stub.c:
./xen/xen-pciback/pci_stub.c:static int __devinit
pcistub_match_one(struct pci_dev *dev,
./xen/xen-pciback/pci_stub.c:static int __devinit pcistub_match(struct
pci_dev *dev)
./xen/xen-pciback/pci_stub.c:static int __devinit
pcistub_init_device(struct pci_dev *dev)
./xen/xen-pciback/pci_stub.c:static int __init
pcistub_init_devices_late(void)
./xen/xen-pciback/pci_stub.c:static int __devinit pcistub_seize(struct
pci_dev *dev)
./xen/xen-pciback/pci_stub.c:static int __devinit pcistub_probe(struct
pci_dev *dev,
./xen/xen-pciback/pci_stub.c:static int __init pcistub_init(void)
./xen/xen-pciback/pci_stub.c:static int __init xen_pcibk_init(void)
./xen/xen-pciback/pci_stub.c:static void __exit
xen_pcibk_cleanup(void)

I think that's enough for now.

The point is, it's not some bizarre coding style choice I made. It's
used by an army of highly skilled programmers (kernel code is
PAINFUL.) These people know what they're doing, more so than you or I.
And they use it.

[toc] | [prev] | [next] | [standalone]

#10623

On Tue, 20 Sep 2011 17:48:40 -0700 (PDT), henry eshbaugh
<henryeshbaugh@gmail.com> wrote:

>The point is, it's not some bizarre coding style choice I made. It's
>used by an army of highly skilled programmers (kernel code is
>PAINFUL.) These people know what they're doing, more so than you or I.
>And they use it.

Some others here may choose to disagree about whether the Linux kernel
coders know more about the C language and what the C standard says
about application name spaces than they do, but:

You should not imitate code in the kernel without knowing specifically
and exactly why they use a particular convention. They may be calling
internal functions of the C runtime library (CRT) where your code MUST
not. This is what is meant by "the implementation". The kernel must be
closely tied to the CRT because the CRT is part and parcel to the way
the kernel supports user applications.

Copying coding conventions where you do not understand the rationale
has a name: Cargo Cult

Kernel code is kernel code and user code is user code. By using kernel
conventions in your USER name space programs you are creating a
potential name space collision.

Using leading underscores is not an indicator of a good programmer,
quite the contrary, it is an indication of a novice C programmer who
is emulating a style he does not understand because he copy-pasted or
has been browsing the CRT sources and has seen the style used and
doesn't understand that the convention is RESERVED to the CRT.

The C standard requires that you don't use leading underscores in your
names for a very specific reason. Just don't do it.

[toc] | [prev] | [next] | [standalone]

#10657

On Sep 20, 10:12 pm, Geoff <ge...@invalid.invalid> wrote:

> You should not imitate code in the kernel without knowing specifically
> and exactly why they use a particular convention. They may be calling
> internal functions of the C runtime library (CRT) where your code MUST
> not. This is what is meant by "the implementation". The kernel must be
> closely tied to the CRT because the CRT is part and parcel to the way
> the kernel supports user applications.



>
> Copying coding conventions where you do not understand the rationale
> has a name: Cargo Cult

I write some kernel code. Habits die hard.

> Kernel code is kernel code and user code is user code. By using kernel
> conventions in your USER name space programs you are creating a
> potential name space collision.

The kernel namespace is separate from user namespace. You have to
specifically link your code against the kernel to cause a namespace
collision. It's like saying having two applications running, both
calling different versions of foo() will have a namespace collision.
It's just not going to happen.

> Using leading underscores is not an indicator of a good programmer,
> quite the contrary, it is an indication of a novice C programmer who
> is emulating a style he does not understand because he copy-pasted or
> has been browsing the CRT sources and has seen the style used and
> doesn't understand that the convention is RESERVED to the CRT.

__foo() isn't a function in the CRT. Neither is __list_reverse(). It's
safe to use.

> The C standard requires that you don't use leading underscores in your
> names for a very specific reason. Just don't do it.

The C implementation I use for my code doesn't. So I consider myself
at liberty to.

[toc] | [prev] | [next] | [standalone]

#10712

On Sep 21, 1:15 pm, henry eshbaugh <henryeshba...@gmail.com> wrote:
> On Sep 20, 10:12 pm, Geoff <ge...@invalid.invalid> wrote:
>
> > The C standard requires that you don't use leading underscores in your
> > names for a very specific reason. Just don't do it.
>
> The C implementation I use for my code doesn't. So I consider myself
> at liberty to.

If you don't value portability, or even guaranteeing that your code
will compile/link with the next upgrade of your implementation, that
is of course a choice you get to make.  But of the portability/
maintainability compromises to choose (and most or all of us make such
choices all the time), stepping on the well defined language namespace
seems to me an odd one.  Folks are welcome to define macros that start
E followed by an uppercase letter, or variables that start __blah or
_Quux, but given easy alternatives not obvious to me why that is a
good choice in general.

[toc] | [prev] | [next] | [standalone]

Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7  Next page →

Back to top | Article view | comp.lang.c

csiph-web