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 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

#10748

On Sep 22, 6:43 pm, David Resnick <lndresn...@gmail.com> wrote:
>  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.
>
The reserved namespace is badly chosen.

For instance the idenitifiers stripspaces() and island step over it,
as does the macro ENDIANNESS.

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

#10757

On Sep 23, 5:45 am, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> The reserved namespace is badly chosen.
>
> For instance the idenitifiers stripspaces() and island step over it,
> as does the macro ENDIANNESS.

Therefore?  We should ignore the implementation namespace?  I miss
your point, or is it just a comment?  When you find a "perfect"
language, please let me know.  In the meantime, as language warts go,
could be worse.  Yes, having language level support for namespaces
would fix it, but, well, that isn't "C", at least not as of now.

-David

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

#10763

On Sep 23, 3:38 pm, David Resnick <lndresn...@gmail.com> wrote:
> On Sep 23, 5:45 am, Malcolm McLean <malcolm.mcle...@btinternet.com>
>
> > For instance the idenitifiers stripspaces() and island step over it,
> > as does the macro ENDIANNESS.
>
> Therefore?  We should ignore the implementation namespace?  
>
If I need an identifier like "strength" or ENGLAND. which is in the
reserved namespace but very unlikely for an implementation to actually
use, I just use it, rather than having SCOTLAND, WALES, IRELAND and
EnGLAND, or whatever subterfuge is necessary.

--
Fuzzy logic trees, machine learning with human-understandable
operations.
http://www.malcolmmclean.site11.com/www

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

#10765

On Sep 23, 10:58 am, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> On Sep 23, 3:38 pm, David Resnick <lndresn...@gmail.com> wrote:> On Sep 23, 5:45 am, Malcolm McLean <malcolm.mcle...@btinternet.com>
> > Therefore?  We should ignore the implementation namespace?  
>
> If I need an identifier like "strength" or ENGLAND. which is in the
> reserved namespace but very unlikely for an implementation to actually
> use, I just use it, rather than having SCOTLAND, WALES, IRELAND and
> EnGLAND, or whatever subterfuge is necessary.

My inclination is to say that is in the same line of reasoning that
causes decisions like
char buf[250];
 is big enough for any file name.  Very unlikely that one will be
bigger than that, right?  I'd rather not guess what is "very unlikely"
when stepping in the implementations namespace.  Make enough "very
unlikely" decisions and eventually one happens.  But each to their
own...

-David

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

#10774

David Resnick <lndresnick@gmail.com> writes:

> On Sep 23, 10:58 am, Malcolm McLean <malcolm.mcle...@btinternet.com>
> wrote:
>> On Sep 23, 3:38 pm, David Resnick <lndresn...@gmail.com> wrote:> On Sep 23, 5:45 am, Malcolm McLean <malcolm.mcle...@btinternet.com>
>> > Therefore?  We should ignore the implementation namespace?  
>>
>> If I need an identifier like "strength" or ENGLAND. which is in the
>> reserved namespace but very unlikely for an implementation to actually
>> use, I just use it, rather than having SCOTLAND, WALES, IRELAND and
>> EnGLAND, or whatever subterfuge is necessary.
>
> My inclination is to say that is in the same line of reasoning that
> causes decisions like
> char buf[250];
>  is big enough for any file name.  Very unlikely that one will be
> bigger than that, right?  I'd rather not guess what is "very unlikely"
> when stepping in the implementations namespace.  Make enough "very
> unlikely" decisions and eventually one happens.  But each to their
> own...

It doesn't "feel" the same to me at all.  From even a formal point of
view, ENGLAND is perfectly OK in a translation using that does not
include errno.h (and even if you do, provided you #undef it first).  And

  #undef strength /* in case I ever include string.h */
  static strength(int x) { ... }

is also perfectly valid.  Being less formal about it, just using these
sorts of identifiers[1] is not likely to go wrong in the same horrid
way that a buffer overrun can (assuming that is what you are referring
to -- a safe read into a buffer that is not big enough is rather
different).

I prefer to avoid using these names at all (even when the standard
assures me it's OK in the specific instance) but when I see them in
other people's code, it certainly feels different to seeing a short
buffer.

I don't extend this feeling to the __ prefix.  Using that is a very odd
choice indeed since it the "most reserved" of all the reserved name
forms -- reserved for any use in any way regardless of any includes.  __
may even (and probably does) introduce keywords into the language.

[1] Every time I read the standard I am reminded of reserved names
(subject to #includes) that I'd forgotten about.  Today's are:

  PRIX_FIXE
  INTEGER_C
  SIGNATURE

-- 
Ben.

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

#10788

On Sep 23, 1:00 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> David Resnick <lndresn...@gmail.com> writes:
> > On Sep 23, 10:58 am, Malcolm McLean <malcolm.mcle...@btinternet.com>
> > wrote:
> >> On Sep 23, 3:38 pm, David Resnick <lndresn...@gmail.com> wrote:> On Sep 23, 5:45 am, Malcolm McLean <malcolm.mcle...@btinternet.com>
> >> > Therefore?  We should ignore the implementation namespace?  
>
> >> If I need an identifier like "strength" or ENGLAND. which is in the
> >> reserved namespace but very unlikely for an implementation to actually
> >> use, I just use it, rather than having SCOTLAND, WALES, IRELAND and
> >> EnGLAND, or whatever subterfuge is necessary.
>
> > My inclination is to say that is in the same line of reasoning that
> > causes decisions like
> > char buf[250];
> >  is big enough for any file name.  Very unlikely that one will be
> > bigger than that, right?  I'd rather not guess what is "very unlikely"
> > when stepping in the implementations namespace.  Make enough "very
> > unlikely" decisions and eventually one happens.  But each to their
> > own...
>
> It doesn't "feel" the same to me at all.  From even a formal point of
> view, ENGLAND is perfectly OK in a translation using that does not
> include errno.h (and even if you do, provided you #undef it first).  And
>
>   #undef strength /* in case I ever include string.h */
>   static strength(int x) { ... }
>
> is also perfectly valid.  Being less formal about it, just using these
> sorts of identifiers[1] is not likely to go wrong in the same horrid
> way that a buffer overrun can (assuming that is what you are referring
> to -- a safe read into a buffer that is not big enough is rather
> different).
>
> I prefer to avoid using these names at all (even when the standard
> assures me it's OK in the specific instance) but when I see them in
> other people's code, it certainly feels different to seeing a short
> buffer.
>
> I don't extend this feeling to the __ prefix.  Using that is a very odd
> choice indeed since it the "most reserved" of all the reserved name
> forms -- reserved for any use in any way regardless of any includes.  __
> may even (and probably does) introduce keywords into the language.
>
> [1] Every time I read the standard I am reminded of reserved names
> (subject to #includes) that I'd forgotten about.  Today's are:
>
>   PRIX_FIXE
>   INTEGER_C
>   SIGNATURE

I agree that not all decisions about 'issue "x" is unlikely so I'll
not code in a way to avoid it' are equal.  And runtime issues (short
buffers) are generally quite a bit worse than compile time conflicts
due to poorly chosen (or reserved) names.  But hitting a compile time
conflict with a 3rd party package that uses reserved identifiers in
its headers or exports symbols in the system namespace would be vexing
to me.  I guess I like the simple rule of not stepping into the
system's namespace to the best of my ability.  Some of the rules (like
__) are obvious.  I didn't know about those you listed above, btw, so
had a quick look at the standard and found them.  It would be nice if
gcc had an option to poke you about using reserved identifiers in non-
system code, but don't see such in its docs (-pedantic doesn't do
it).

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

#10793

David Resnick <lndresnick@gmail.com> writes:
<snip>
>                                           But hitting a compile time
> conflict with a 3rd party package that uses reserved identifiers in
> its headers or exports symbols in the system namespace would be vexing
> to me.

That's something I did not consider.  I was (rather narrowly) thinking
of my private code.  If it's code you can't change, it is going to much
more annoying.

<snip>
>                                                   It would be nice if
> gcc had an option to poke you about using reserved identifiers in non-
> system code, but don't see such in its docs (-pedantic doesn't do
> it).

I don't think there is one.  It would be a very useful warning.

-- 
Ben.

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

#10823

Ben Bacarisse wrote:

> From even a formal point of
> view, ENGLAND is perfectly OK in a translation using that does not
> include errno.h
> (and even if you do, provided you #undef it first).  And
> 
>   #undef strength /* in case I ever include string.h */
>   static strength(int x) { ... }
> 
> is also perfectly valid.  

I have two problems with that:

1   The comment should be 
    /* in case I ever include string.h or stdlib.h */

2   If strength is the name of a function in string.h
    and string.h is included,
    then that #undef will not allow you redefine strength..

-- 
pete

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

#10832

pete <pfiland@mindspring.com> writes:

> Ben Bacarisse wrote:
>
>> From even a formal point of
>> view, ENGLAND is perfectly OK in a translation using that does not
>> include errno.h
>> (and even if you do, provided you #undef it first).  And
>> 
>>   #undef strength /* in case I ever include string.h */
>>   static strength(int x) { ... }
>> 
>> is also perfectly valid.  
>
> I have two problems with that:

and now, so do I.

> 1   The comment should be 
>     /* in case I ever include string.h or stdlib.h */
>
> 2   If strength is the name of a function in string.h
>     and string.h is included,
>     then that #undef will not allow you redefine strength..

Both excellent points.  Thanks.  I should have said that strength
is fine provided it does not have external linkage and neither of the
headers you cite are included.

-- 
Ben.

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

#10769

On Sep 23, 10:58 am, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> On Sep 23, 3:38 pm, David Resnick <lndresn...@gmail.com> wrote:> On Sep 23, 5:45 am, Malcolm McLean <malcolm.mcle...@btinternet.com>
>
> > > For instance the idenitifiers stripspaces() and island step over it,
> > > as does the macro ENDIANNESS.
>
> > Therefore?  We should ignore the implementation namespace?  
>
> If I need an identifier like "strength" or ENGLAND. which is in the
> reserved namespace but very unlikely for an implementation to actually
> use, I just use it, rather than having SCOTLAND, WALES, IRELAND and
> EnGLAND, or whatever subterfuge is necessary.

Of course one can get more verbose by adding a prefix, like REGION_ if
strict adherence is necessary.  But I tend to have the same attitude
as you for those kinds of identifiers.

From this discussion, it's obvious that eshbaugh is a part of the
rebel alliance, and a *traitor*.  He has not fully succumbed to the
"standard" side of the force ... yet (cue Imperial March).

(I'll never join you!!!)

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

#10724

henry eshbaugh <henryeshbaugh@gmail.com> writes:
> On Sep 20, 10:12 pm, Geoff <ge...@invalid.invalid> wrote:
> > Copying coding conventions where you do not understand the rationale
> > has a name: Cargo Cult
> 
> I write some kernel code. Habits die hard.

linux-2.6$ git log | grep -i eshbaugh
linux-2.6$

> > 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.

You have misunderstood Geoff, your retort is irrelevant to his point.
The name space collision Geoff is talking about is between your user
code and the CRT.

> > 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.

Do you know how difficult it would be for me to change the CRT I use
at home and at work such that it did have a __foo()? Don't think too
long, as I'd already have done it.

> > 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 only care about your code running on one platform and only
using one toolchain - at that, only one version of the platform and
the toolchain - then you have the right to construct your own play
area where you break the rules. However, do not expect others to join
you there, and certainly do not expect others to want you to join
their play area.

Phil
-- 
"Religion is what keeps the poor from murdering the rich."
-- Napoleon

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

#10624

henry eshbaugh <henryeshbaugh@gmail.com> writes:
> 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 haven't answered this question.

>> 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.

[snip]

C99 7.1.3p1:

    All identifiers that begin with an underscore and either an
    uppercase letter or another underscore are always reserved for any
    use.

    All identifiers that begin with an underscore are always reserved
    for use as identifiers with file scope in both the ordinary and tag
    name spaces.

    [more reserved identifiers omitted]

    No other identifiers are reserved. If the program declares or
    defines an identifier in a context in which it is reserved (other
    than as allowed by 7.1.4), or defines a reserved identifier as a
    macro name, the behavior is undefined.

The behavior of your program is undefined because you used the name
"__foo".  It would have been well defined if you hadn't done that.

I've give you the facts; what you do with them is up to you.

-- 
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]

#10654

On Sep 20, 10:51 pm, Keith Thompson <ks...@mib.org> wrote:

> >> Exactly what benefit do you get by calling your own function "__foo"
> >> (rather than, say, "foo__")?
>
> You haven't answered this question.

Absolutely nothing. I arbitrarily decided to put leading underscores
in. Apparently, some people have a problem with it.

>
> [snip]
>
> C99 7.1.3p1:
>
>     All identifiers that begin with an underscore and either an
>     uppercase letter or another underscore are always reserved for any
>     use.
>
>     All identifiers that begin with an underscore are always reserved
>     for use as identifiers with file scope in both the ordinary and tag
>     name spaces.
>
>     [more reserved identifiers omitted]
>
>     No other identifiers are reserved. If the program declares or
>     defines an identifier in a context in which it is reserved (other
>     than as allowed by 7.1.4), or defines a reserved identifier as a
>     macro name, the behavior is undefined.
>
> The behavior of your program is undefined because you used the name
> "__foo".  It would have been well defined if you hadn't done that.

And yet it works the same on my platform. It's a trivial thing; if it
doesn't work for you, you can change it with ease.

> I've give you the facts; what you do with them is up to you.

I choose to ignore you and revel in the glory that is my platform.
It's my business.

Critique my code for what it is, not how pretty one identifier is
compared to another.

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

#10666

henry eshbaugh <henryeshbaugh@gmail.com> writes:
> On Sep 20, 10:51 pm, Keith Thompson <ks...@mib.org> wrote:
>
>> >> Exactly what benefit do you get by calling your own function "__foo"
>> >> (rather than, say, "foo__")?
>>
>> You haven't answered this question.
>
> Absolutely nothing. I arbitrarily decided to put leading underscores
> in. Apparently, some people have a problem with it.

The language standard has a problem with it.

[...]

>> The behavior of your program is undefined because you used the name
>> "__foo".  It would have been well defined if you hadn't done that.
>
> And yet it works the same on my platform. It's a trivial thing; if it
> doesn't work for you, you can change it with ease.

I could write a program that works if the hostname of the machine
it's running on is "kvetch", and fails randomly if it isn't.
The program would work just fine on my system, and I could make
the same argument you're making.

>> I've give you the facts; what you do with them is up to you.
>
> I choose to ignore you and revel in the glory that is my platform.
> It's my business.

Yes, it is.

> Critique my code for what it is, not how pretty one identifier is
> compared to another.

If you post code in public, it will be critiqued.  If you don't want it
critiqued, don't post it.

I am not critiquing it for "how pretty one identifier is compared to
another".  If you think I am, then you still don't understand what I'm
telling you.

We are critiquing your code for what it is: non-portable code whose
behavior is undefined, for reasons clearly stated in the C standard.

And in case it's not clear *we're trying to help you*.  Pointing out
problems in your code is not a personal attack.

If you want to write non-portable code, you can do so.  Often there
are very good reasons for doing so (but not in this case, as far as I
can tell).  What I recommend is that you should be *aware* of why and
how your code is non-portable, so you can make an informed decision.

-- 
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]

#10625

On 09/20/2011 08:48 PM, henry eshbaugh wrote:
> 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.

"coding style" is not a term ordinarily used to describe deliberate
adoption of practices that, according to the C standard, have undefined
behavior.

> And it's not just me. You know who else happens to do that? The small
> army of Linux kernel programmers.

Guess what: the Linux kernal is part of a C implementation. The key
reason why you're not supposed to use these names is because they ARE
supposed to use them. They're NOT supposed to use the names that are
reserved for your use.

> 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.

Both Keith and I are very experienced programmers with a comprehensive
and detailed knowledge of precisely what it is that the C standard
requires and allows. I would not recommend automatically assuming that
those people know more than we do, just because they know a lot more
than you do.

> And they use it.

Yes - because they know enough to recognize which name space has been
reserved for their use - it is NOT the same name space that has been
reserved for your use. I recommend you acquire the same understanding
they have; because that same understanding will result in you using very
different naming conventions than they do.
-- 
James Kuyper

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

#10655

> "coding style" is not a term ordinarily used to describe deliberate
> adoption of practices that, according to the C standard, have undefined
> behavior.

I used a term where you didn't expect to see it. Deal with it.

> Guess what: the Linux kernal is part of a C implementation. The key
> reason why you're not supposed to use these names is because they ARE
> supposed to use them. They're NOT supposed to use the names that are
> reserved for your use.

The Linux kernel is _not_ a C implementation. Glibc is a C
implementation.

> Both Keith and I are very experienced programmers with a comprehensive
> and detailed knowledge of precisely what it is that the C standard
> requires and allows. I would not recommend automatically assuming that
> those people know more than we do, just because they know a lot more
> than you do.

That's wonderful. My choices work for me. I never asked you to adopt
it, I never asked you to critique it, and I never asked to be involved
in a flame war with either of you. My choices are my choices and your
choices are your choices. What I decide to do with underscores is my
business.

> Yes - because they know enough to recognize which name space has been
> reserved for their use - it is NOT the same name space that has been
> reserved for your use. I recommend you acquire the same understanding
> they have; because that same understanding will result in you using very
> different naming conventions than they do.

You realize that the kernel namespace, the glibc namespace, and the
application namespace are three distinct things, right?

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

#10739

henry eshbaugh <henryeshbaugh@gmail.com> writes:
> > "coding style" is not a term ordinarily used to describe deliberate
> > adoption of practices that, according to the C standard, have undefined
> > behavior.
> 
> I used a term where you didn't expect to see it. Deal with it.
> 
> > Guess what: the Linux kernal is part of a C implementation. The key
> > reason why you're not supposed to use these names is because they ARE
> > supposed to use them. They're NOT supposed to use the names that are
> > reserved for your use.
> 
> The Linux kernel is _not_ a C implementation. Glibc is a C
> implementation.

You think the linux kernel links to glibc? So you believe that
kernel code could just include a call to, say strtok(), and 
that would get resolved to glibc's implementation?

Knock, knock, knock - who's that at the door? Oh, it's Captain
Whatthefuck.

I'll have some of what you're smoking. But I'll only partake 
once I've finished my day's work as a linux kernel programmer
and one of the company's tree maintainers, thank you. (Yay, 8
days until I am _the_ maintainer, thanks to the Elopocalypse.)

Phil
-- 
"Religion is what keeps the poor from murdering the rich."
-- Napoleon

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

#10764

Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> henry eshbaugh <henryeshbaugh@gmail.com> writes:
>> > "coding style" is not a term ordinarily used to describe deliberate
>> > adoption of practices that, according to the C standard, have undefined
>> > behavior.
>> 
>> I used a term where you didn't expect to see it. Deal with it.
>> 
>> > Guess what: the Linux kernal is part of a C implementation. The key
>> > reason why you're not supposed to use these names is because they ARE
>> > supposed to use them. They're NOT supposed to use the names that are
>> > reserved for your use.
>> 
>> The Linux kernel is _not_ a C implementation. Glibc is a C
>> implementation.
>
> You think the linux kernel links to glibc? So you believe that
> kernel code could just include a call to, say strtok(), and 
> that would get resolved to glibc's implementation?

[...]

I didn't see anything in what henry eshbaugh wrote that implies
that the Linux kernel links to glibc.  He was merely refuting
(correctly, I believe) someone else's claim that the kernel is part
of a C implementation.

-- 
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]

#10776

Keith Thompson <kst-u@mib.org> writes:

> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
>> henry eshbaugh <henryeshbaugh@gmail.com> writes:
>>> > "coding style" is not a term ordinarily used to describe deliberate
>>> > adoption of practices that, according to the C standard, have undefined
>>> > behavior.
>>> 
>>> I used a term where you didn't expect to see it. Deal with it.
>>> 
>>> > Guess what: the Linux kernal is part of a C implementation. The key
>>> > reason why you're not supposed to use these names is because they ARE
>>> > supposed to use them. They're NOT supposed to use the names that are
>>> > reserved for your use.
>>> 
>>> The Linux kernel is _not_ a C implementation. Glibc is a C
>>> implementation.
>>
>> You think the linux kernel links to glibc? So you believe that
>> kernel code could just include a call to, say strtok(), and 
>> that would get resolved to glibc's implementation?
>
> [...]
>
> I didn't see anything in what henry eshbaugh wrote that implies
> that the Linux kernel links to glibc.  He was merely refuting
> (correctly, I believe) someone else's claim that the kernel is part
> of a C implementation.

This is tangential to the issue of reserved identifiers, but I've always
thought of the kernel as part of a C implementation.  A (possibly naive)
reading of this definition:

  3.12
  1 implementation

    particular set of software, running in a particular translation
    environment under particular control options, that performs
    translation of programs for, and supports execution of functions in,
    a particular execution environment

seems to support that view.  I would have said that the kernel (of the
compiler's target system, of course) "supports execution of functions
in, a particular execution environment".

-- 
Ben.

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

#16125

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Keith Thompson <kst-u@mib.org> writes:
>
>> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
>>> henry eshbaugh <henryeshbaugh@gmail.com> writes:
>>>> > "coding style" is not a term ordinarily used to describe deliberate
>>>> > adoption of practices that, according to the C standard, have undefined
>>>> > behavior.
>>>> 
>>>> I used a term where you didn't expect to see it. Deal with it.
>>>> 
>>>> > Guess what: the Linux kernal is part of a C implementation. The key
>>>> > reason why you're not supposed to use these names is because they ARE
>>>> > supposed to use them. They're NOT supposed to use the names that are
>>>> > reserved for your use.
>>>> 
>>>> The Linux kernel is _not_ a C implementation. Glibc is a C
>>>> implementation.
>>>
>>> You think the linux kernel links to glibc? So you believe that
>>> kernel code could just include a call to, say strtok(), and 
>>> that would get resolved to glibc's implementation?
>>
>> [...]
>>
>> I didn't see anything in what henry eshbaugh wrote that implies
>> that the Linux kernel links to glibc.  He was merely refuting
>> (correctly, I believe) someone else's claim that the kernel is part
>> of a C implementation.
>
> This is tangential to the issue of reserved identifiers, but I've always
> thought of the kernel as part of a C implementation.  A (possibly naive)
> reading of this definition:
>
>   3.12
>   1 implementation
>
>     particular set of software, running in a particular translation
>     environment under particular control options, that performs
>     translation of programs for, and supports execution of functions in,
>     a particular execution environment
>
> seems to support that view.  I would have said that the kernel (of the
> compiler's target system, of course) "supports execution of functions
> in, a particular execution environment".

That's for things like the standard library.  A kernel _provides_
an execution environment, but nothing in it is particular or specific
to C.  Rather, it is part of a system that may support a conforming
implemention, as mentioned in 1 p2 (last bullet item).

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

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

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

csiph-web