Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Reversing a linked list

Reply
Thread Tools

Reversing a linked list

 
 
David Resnick
Guest
Posts: n/a
 
      09-23-2011
On Sep 23, 10:58*am, Malcolm McLean <(E-Mail Removed)>
wrote:
> On Sep 23, 3:38*pm, David Resnick <(E-Mail Removed)> wrote:> On Sep23, 5:45*am, Malcolm McLean <(E-Mail Removed)>
> > 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
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      09-23-2011
Phil Carmody <(E-Mail Removed)> writes:
> henry eshbaugh <(E-Mail Removed)> 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) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
ImpalerCore
Guest
Posts: n/a
 
      09-23-2011
On Sep 23, 10:58*am, Malcolm McLean <(E-Mail Removed)>
wrote:
> On Sep 23, 3:38*pm, David Resnick <(E-Mail Removed)> wrote:> On Sep23, 5:45*am, Malcolm McLean <(E-Mail Removed)>
>
> > > 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!!!)

 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      09-23-2011
David Resnick <(E-Mail Removed)> writes:

> On Sep 23, 10:58*am, Malcolm McLean <(E-Mail Removed)>
> wrote:
>> On Sep 23, 3:38*pm, David Resnick <(E-Mail Removed)> wrote:> On Sep 23, 5:45*am, Malcolm McLean <(E-Mail Removed)>
>> > 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.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      09-23-2011
Keith Thompson <(E-Mail Removed)> writes:

> Phil Carmody <(E-Mail Removed)> writes:
>> henry eshbaugh <(E-Mail Removed)> 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.
 
Reply With Quote
 
David Resnick
Guest
Posts: n/a
 
      09-23-2011
On Sep 23, 1:00*pm, Ben Bacarisse <(E-Mail Removed)> wrote:
> David Resnick <(E-Mail Removed)> writes:
> > On Sep 23, 10:58*am, Malcolm McLean <(E-Mail Removed)>
> > wrote:
> >> On Sep 23, 3:38*pm, David Resnick <(E-Mail Removed)> wrote:> On Sep 23, 5:45*am, Malcolm McLean <(E-Mail Removed)>
> >> > 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).
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      09-23-2011
David Resnick <(E-Mail Removed)> 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.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      09-23-2011
pete <(E-Mail Removed)> 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.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      09-24-2011
On 09/23/2011 04:49 PM, Phil Carmody wrote:
> Keith Thompson <(E-Mail Removed)> writes:
>> Phil Carmody <(E-Mail Removed)> writes:
>>> henry eshbaugh <(E-Mail Removed)> writes:

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

>
> The kernel contains part of a C implementation at least as much
> as glibc does. Henry magically disappeared the word "part of" in
> his response. 'is' was perhaps overstating the claim, ...


I hadn't even noticed that confusion on his part.

> ... but there
> is undeniably C implementation in the linux kernel (e.g. in the
> include and lib directories).


The relevant question is not whether it's part of the implementation,
but whether identifiers used in the kernel could interfere with names
used in ordinary C code. Quite frankly, I have no idea, since I've never
had to deal with the kernel directly. A quick web search didn't resolve
that question in my mind: I didn't get too few hits, but rather way too
many, and I couldn't find one that clearly addressed that issue. I'm a
little surprised that no one other than Henry has directly commented on
that - I'm not inclined to take his opinions on the matter as gospel.

It was my annoyance at Henry's pig-headedness which led me to make the
mistake of speaking authoritatively on a subject on which I am not at
all an authority; I regretted that mistake within minutes of sending the
message.
--
James Kuyper
 
Reply With Quote
 
Phil Carmody
Guest
Posts: n/a
 
      09-24-2011
James Kuyper <(E-Mail Removed)> writes:
> On 09/23/2011 04:49 PM, Phil Carmody wrote:
> > Keith Thompson <(E-Mail Removed)> writes:
> >> Phil Carmody <(E-Mail Removed)> writes:
> >>> henry eshbaugh <(E-Mail Removed)> writes:

> ...
> The relevant question is not whether it's part of the implementation,
> but whether identifiers used in the kernel could interfere with names
> used in ordinary C code.


They cannot any more than identifiers in different userspace
programs can interfere with each other. However, identifiers
in separate libraries can interfere with each other, and with
the program they're being loaded into.

Phil
--
"Religion is what keeps the poor from murdering the rich."
-- Napoleon
 
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
Reversing a singly linked list saki C Programming 2 07-06-2008 06:37 PM
Linked list within a linked list joshd C++ 12 10-02-2006 08:57 AM
Linked list, New try (was:Linked list, no out put,help) fool C Programming 14 07-03-2006 12:29 AM
Generating a char* from a linked list of linked lists Chris Ritchey C++ 7 07-10-2003 10:12 PM
Generating a char* from a linked list of linked lists Chris Ritchey C Programming 7 07-10-2003 10:12 PM



Advertisments