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

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

Compatibility question

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

Contents

  Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-20 03:08 +0000
    Re: Compatibility question Ian Collins <ian-news@hotmail.com> - 2012-10-20 16:20 +1300
      Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-20 11:50 +0100
        Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-20 11:41 -0700
          Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-21 23:04 +0000
            Re: Compatibility question Barry Schwarz <schwarzb@dqel.com> - 2012-10-21 20:27 -0700
      Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-20 04:01 +0000
        Re: Compatibility question Ian Collins <ian-news@hotmail.com> - 2012-10-21 09:26 +1300
          Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-21 22:54 +0000
            Re: Compatibility question Ian Collins <ian-news@hotmail.com> - 2012-10-22 12:29 +1300
              Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-21 23:50 +0000
                Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-22 02:27 +0100
                  Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 02:28 +0000
                    Re: Compatibility question Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-22 11:18 -0400
                      Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 16:19 +0000
                      Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-22 17:37 +0100
                        Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-22 17:40 +0100
                    Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-22 17:30 +0100
                      Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 17:23 +0000
                        Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-22 10:52 -0700
                          Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 18:42 +0000
                            Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-22 21:06 +0100
                              Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 22:52 +0000
                                Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-23 03:33 +0100
                                  Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-23 12:28 +0000
                                    Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 16:45 +0100
                                      Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-23 17:53 +0000
                                      Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-23 12:41 -0700
                                        Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 21:28 +0100
                                      Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-23 20:57 +0100
                                Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-23 12:26 -0700
                                  Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-23 20:39 +0000
                                    Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-23 15:53 -0700
                                      Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-24 00:57 +0100
                                        Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-23 20:06 -0700
                                          Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-24 11:18 +0100
                                            Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 12:04 -0700
                                              Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-24 23:10 +0100
                                                Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 16:58 -0700
                                                  Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-25 01:46 +0100
                                                    Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 19:40 -0700
                                      Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-24 20:20 +0000
                                        Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 14:38 -0700
                                          Re: Compatibility question James Kuyper <jameskuyper@verizon.net> - 2012-10-24 17:55 -0400
                                            Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 16:29 -0700
                                        Re: Compatibility question Greg Martin <greg@softsprocket.com> - 2012-10-24 15:21 -0700
                                          Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-26 03:30 +0000
                                            Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-26 13:02 +0100
                                              Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-27 00:04 +0000
                                                Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-27 20:15 +0100
                                                Re: Compatibility question Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-10-27 16:36 -0600
                                                  Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-28 17:36 +0000
                                          Re: Compatibility question Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-10-27 22:42 +0300
                                            Re: Compatibility question Greg Martin <greg@softsprocket.com> - 2012-10-27 14:30 -0700
                                              Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-27 22:57 +0100
                                                Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-27 17:04 -0700
                                                  Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-27 17:14 -0700
                                                    Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-27 18:04 -0700
                                        Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 16:46 -0700
                                          Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-25 01:18 +0000
                                    Re: Compatibility question Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-10-27 21:08 +0300
                                      Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-28 17:38 +0000
                            Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 00:38 +0100
                            Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-22 16:50 -0700
                              Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-23 12:33 +0000
                        Re: Compatibility question Öö Tiib <ootiib@hot.ee> - 2012-10-22 14:23 -0700
                          Re: Compatibility question James Kuyper <jameskuyper@verizon.net> - 2012-10-22 17:26 -0400
                          Re: Compatibility question Ian Collins <ian-news@hotmail.com> - 2012-10-23 10:55 +1300
                          Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 23:27 +0000
                        Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-22 22:44 +0100
                          Re: Compatibility question Les Cargill <lcargill99@comcast.com> - 2012-10-22 17:15 -0500
                            Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 00:13 +0100
                          Re: Compatibility question James Kuyper <jameskuyper@verizon.net> - 2012-10-22 18:35 -0400
                            Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 00:14 +0100
                          Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 23:42 +0000
                            Re: Compatibility question Ian Collins <ian-news@hotmail.com> - 2012-10-23 13:35 +1300
                          Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-22 17:01 -0700
                            Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 01:47 +0100
                Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-21 19:27 -0700

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

#27664

"BartC" <bc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnsj93tobp.fsf@nuthaus.mib.org...
>> "BartC" <bc@freeuk.com> writes:
>
>> But I'm still interested in what you mean by the word "variable".
>> Nothing in your followup answers that question.

[snip]

> Or the short version: a named object..

Ok, a variable is a named object; that's really all I was looking
for.  That's about the same way I think of it.  Interestingly,
a const-qualified named object is a "variable", even though it's
not "able to vary".  I'm not sure whether a struct or union member
is a "variable" (is "foo.bar" a name?), but I'm not sure how much
that matters.

Your earlier article seemed to imply that a variable is a name, not the
object that name refers to, but I guess that's not what you actually
meant.

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

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

#27648

On Tue, Oct 23, 2012 at 03:53:21PM -0700, Keith Thompson wrote:
> Steve Thompson <stevet810@gmail.com> writes:
> > On Tue, Oct 23, 2012 at 12:26:05PM -0700, Keith Thompson wrote:
> >> Steve Thompson <stevet810@gmail.com> writes:
> >> > On Mon, Oct 22, 2012 at 09:06:39PM +0100, Ben Bacarisse wrote:
> >> [...]
> >> >> Whatever goes on under the hood (and I'd dispute that 'a' is "really a
> >> >> pointer") it's much easier to learn a language in its own terms, at
> >> >> least as far as that's possible.
> >> >
> >> > Well, no.  'a' is never a pointer as such in the terms of the language
> >> > syntax, but its treatment by the compiler internally is nominally
> >> > equivalent to they way it handles a pointer, with the exception that
> >> > the language grammar forbids its use in the program text as a pointer.
> >> 
> >> I don't believe that's true.  Do you have some evidence that it is?
> >
> > The distinction is largely moot.  In a practical sense, all variables
> > have a value which is stored somewhere.  The compiler is making an
> > explicit use of a pointer when it does something with the value.  The
> > problem is that "use" in this context may as well be referring to ether
> > or memory and there's no easy way of knowing which it is.
> 
> When you say "explicit use of a pointer", do you mean that there's
> a pointer *object* somewhere, or are you talking about a pointer
> *value*, also known as an "address"?

I suppose address is the better term, but that does not work for
registers.
 
> How much do you know about the internal workings of compilers?

Precious little.  My brain is only starting to think about
interpreters; I plan to hold off polluting my brain with compiler
internals until I find a pressing need to write one.

> >> > In a simplistic sense, all variables are pointers to a segment of
> >> > program data, modifiable or otherwise.
> 
> No, a variable is not a pointer to a chunk of memory, it *is* a chunk of
> memory (which can contain a value at execution time).
> 
> More precisely, the C standard doesn't define the word "variable", but I
> presume that a "variable" is a kind of "object", which is defined as a
> "region of data storage in the execution environment, the contents of
> which can represent values".  Not a pointer in sight.

My bad, I have assumed that a variable must be distinguished from
other variables by an address, which implies a pointer of some sort,
but you might choose to call that an identifier instead.

More generally, a value must be distinguished from other values with a
unique identifier.  In a program, we call this identifier a 'named
variable', which in a sense may be thought of as is its 'address' by
virtue of its entry in the program's 'dictionary' of identifiers.
Anything else implies magic of some unspecified/unknowable nature, and
I'm not all that keen on the idea of magic.

This 'address' has distinct qualities in the compiler's representation
of the program and in the assembled object code, which I suppose are
representative of distinct, but related ontologies.  The standard, of
course, is not concerned with the philosophy of computer software,
only its behavior in the execution environment.

> >> > values may move around in and from RAM to CPU registers and back while
> >> > being identified as a single consistent entity.  This helps to
> >> > illustrate the difference between a language and its implementation.
> >> 
> >> So a char object is really a pointer to char, an int object is
> >> really a pointer to int, and a char** object is really a char**?
> 
> Sorry, what I meant to write is that a char** object is really (in your
> model) a char***, i.e., a pointer to a char**.
> 
> > No, a char ** object is a pointer to a char ** object.
> 
> Was that really what you meant to type?  I messed up the number of *s,
> so I can hardly criticize you for doing the same thing, but I'd like to
> know what you meant.

I must suggest that the fundamental nature of objects is that they
have an identifier and existence.  Existence implies location,
especially in a computer program.  Proving the proposition that
identifiers have existence independent of their object I leave as an
exercise for the student.
 
> In your model, as I understand it, an int object is really a pointer to
> int, or an int*.  It would follow that a char** object is really a
> pointer to a char**, or a char***.  Or am I misunderstanding you?

Perhaps you can revisit that question after considering the
philosophical statements above.
 
> In fact, an int object is an int object.  I find that so obvious
> that it seems odd to have to state it.  For an operation on such
> an object, a compiler might have to generate code that determines
> that object's address.  That does not in any sense imply that an
> int object is "really" a pointer.  You can construct a pointer to
> an int object, but the pointer and the object it points to are two
> different things.

We're using pointer in two different senses:  in the sense defined by
the C standard, and in the sense that an identifier points to
an object, by definition.  The concept of 'pointer' is implicit to the
idea of 'object'.  You seem to be confused by the use of pointer to
refer to anything other than a C pointer object.

Religions seem to rely on that same kind of confusion to obscure the
origins and nature of some kinds of religious 'knowledge'.  Moreover,
thinking about philosophy and ontology is all but outlawed today.

> >> I think you're simply adding an extra -- and unnecessary -- level
> >> of indirection, and of confusion.
> >> 
> >> There may also be some confusion between pointer *objects* and
> >> pointer *values* (i.e., addresses).
> >
> > Let me say again that I am not talking about addresses as might be
> > referenced in object code.  Perhaps it will clarify that I am thinking
> > of something like the phase space of the compiler as it is building
> > the tree representing the source code of the program.
> 
> And we're getting even farther afield from the actual semantics of a C
> program.

Maybe.
 
> An object doesn't even exist during compilation.  Memory for it
> is allocated as the program is executed.  Pointers (either pointer
> objects or pointer values) do not exist until the program executes.
> The "phase space" of the compiler is irrelevant.

Of course it exists, or rather the object's identifier implies its
existence in the execution environment.  If it did not, you could not
write programs and compilers could not compile programs.  Furthermore,
the existence of the execution environment is in some sense guaranteed
by the existence of the compiler, is it not?
 
> When you claim that a struct object is "really" a pointer, are you
> referring to something that exists internally to a compiler during
> compilation?  If so, of what possible use is it to understanding
> what a struct object is?
>
> >> If I define an object of struct type and perform some operation
> >> on it (say, a simple assignment), the generated code might very
> >> well refer to the address of the object.  There is no *object*
> >> of pointer type, either explicitly or implicitly.
> >
> > That could depend on the way the compiler is designed.
> 
> Perhaps.  But an object of pointer-to-struct type is a region
> of memory holding the address of the struct object.  Why would a
> compiler allocate and initialize such a pointer object, or generate
> code to do so, in the absence of C code to take the addrss of the
> struct object?

Because it is natural to do so.  The fact that your compiler copies
such structures in assignment contexts (seemingly) one field at a time
is an artifact of its design.  Another compiler might use a form of
memcpy(), in which case there would have to be a pointer -- just not
one that you defined explicitly in your source code.

> >> Struct objects are very often manipulated via pointers (simulating
> >> by-reference argument passing, for example), but that's a coding
> >> convention, not anything inherent to the language.
> >
> > Agreed.
> 
> So where do these "pointers" you keep talking about come from?
> In what sense do they exist?
> 
> [big snip]
> 
> > See my comment above regarding the compiler's phase space, although
> > I'm not quite sure that is the best term to use in describing what I
> > am thinking.
> 
> I'm pretty sure it isn't.

I think the philosophical perspective better illustrates what I was
thinking.  The phase space is referential to a program's execution
environment, which we generally assume to exist, and hence any object
in that phase space has an address which is, by definition, a pointer.

I hope this makes things clearer.



Regards,

Steve Thompson

-- 
GOTO's are like guns.  Safety is entirely contingent on the user.

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

#27650

Steve Thompson <stevet810@gmail.com> writes:
> On Tue, Oct 23, 2012 at 03:53:21PM -0700, Keith Thompson wrote:
>> Steve Thompson <stevet810@gmail.com> writes:
>> > On Tue, Oct 23, 2012 at 12:26:05PM -0700, Keith Thompson wrote:
>> >> Steve Thompson <stevet810@gmail.com> writes:
>> >> > On Mon, Oct 22, 2012 at 09:06:39PM +0100, Ben Bacarisse wrote:
>> >> [...]
>> >> >> Whatever goes on under the hood (and I'd dispute that 'a' is "really a
>> >> >> pointer") it's much easier to learn a language in its own terms, at
>> >> >> least as far as that's possible.
>> >> >
>> >> > Well, no.  'a' is never a pointer as such in the terms of the language
>> >> > syntax, but its treatment by the compiler internally is nominally
>> >> > equivalent to they way it handles a pointer, with the exception that
>> >> > the language grammar forbids its use in the program text as a pointer.
>> >> 
>> >> I don't believe that's true.  Do you have some evidence that it is?
>> >
>> > The distinction is largely moot.  In a practical sense, all variables
>> > have a value which is stored somewhere.  The compiler is making an
>> > explicit use of a pointer when it does something with the value.  The
>> > problem is that "use" in this context may as well be referring to ether
>> > or memory and there's no easy way of knowing which it is.
>> 
>> When you say "explicit use of a pointer", do you mean that there's
>> a pointer *object* somewhere, or are you talking about a pointer
>> *value*, also known as an "address"?
>
> I suppose address is the better term, but that does not work for
> registers.

Neither "address" nor "pointer" works for register objects -- or for bit
fields.

>> How much do you know about the internal workings of compilers?
>
> Precious little.  My brain is only starting to think about
> interpreters; I plan to hold off polluting my brain with compiler
> internals until I find a pressing need to write one.

Then I'm mystified by your decision to try to understand C
semantics in terms of compiler internals.  There's a perfectly good
definition of C semantics: the ISO C standard; the latest draft
is <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf>.

>> >> > In a simplistic sense, all variables are pointers to a segment of
>> >> > program data, modifiable or otherwise.
>> 
>> No, a variable is not a pointer to a chunk of memory, it *is* a chunk of
>> memory (which can contain a value at execution time).
>> 
>> More precisely, the C standard doesn't define the word "variable", but I
>> presume that a "variable" is a kind of "object", which is defined as a
>> "region of data storage in the execution environment, the contents of
>> which can represent values".  Not a pointer in sight.
>
> My bad, I have assumed that a variable must be distinguished from
> other variables by an address, which implies a pointer of some sort,
> but you might choose to call that an identifier instead.

An identifier is a character string that exists in source code.  An
object is a "region of data storage in the execution environment, the
contents of which can represent values".  The standard doesn't define
the term "variable", and uses it in that sense only in a few footnotes,
but it consistently uses the word "variable" to refer to objects.

Given:

    int obj;
    register int reg;
    struct {
        int member;
        int bit_field:8;
    }s;

obj, reg, s, s.member, and s.bit_field are all objects (or, perhaps more
precisely, are all names by which we can refer to objects).  Not all of
them have addresses.  Which of them are "variables" might be an
interesting question, but I don't think it would illumate what we're
talking about.  I suggest we stick to the term "object" from now on,
since it has an unambiguous meaning.

> More generally, a value must be distinguished from other values with a
> unique identifier.  In a program, we call this identifier a 'named
> variable', which in a sense may be thought of as is its 'address' by
> virtue of its entry in the program's 'dictionary' of identifiers.
> Anything else implies magic of some unspecified/unknowable nature, and
> I'm not all that keen on the idea of magic.

Now you introduce the term "value", which is very different from an
"object".  The expression `42`, when evaluated, yields a "value" which
is not associated with any object.  And not all objects have names; some
of them are anonymous:

    int *ptr = malloc(sizeof *ptr);
    // *ptr is an int object with no name of its own

An object defined inside a recursive function will have a single
entry in the compiler's symbol table, but can have multiple
instances, with distinct addresses, during execution.  An object
defined in a function that's never called likewise has a single
symbol table entry, but has *no* address during execution.

These are just some of the reasons why using the term "address" to
refer to a compiler symbol table entry (which is what I think you
mean by "its entry in the program's 'dictionary' of identifiers")
is just wrong and confusing.

> This 'address' has distinct qualities in the compiler's representation
> of the program and in the assembled object code, which I suppose are
> representative of distinct, but related ontologies.  The standard, of
> course, is not concerned with the philosophy of computer software,
> only its behavior in the execution environment.

The standard is not concerned either with the "philosophy of computer
software" or with the details of compiler implementation.

>> >> > values may move around in and from RAM to CPU registers and back while
>> >> > being identified as a single consistent entity.  This helps to
>> >> > illustrate the difference between a language and its implementation.
>> >> 
>> >> So a char object is really a pointer to char, an int object is
>> >> really a pointer to int, and a char** object is really a char**?
>> 
>> Sorry, what I meant to write is that a char** object is really (in your
>> model) a char***, i.e., a pointer to a char**.
>> 
>> > No, a char ** object is a pointer to a char ** object.
>> 
>> Was that really what you meant to type?  I messed up the number of *s,
>> so I can hardly criticize you for doing the same thing, but I'd like to
>> know what you meant.
>
> I must suggest that the fundamental nature of objects is that they
> have an identifier and existence.  Existence implies location,
> especially in a computer program.  Proving the proposition that
> identifiers have existence independent of their object I leave as an
> exercise for the student.

You didn't answer my question.  And not all objects have identifiers.

>> In your model, as I understand it, an int object is really a pointer to
>> int, or an int*.  It would follow that a char** object is really a
>> pointer to a char**, or a char***.  Or am I misunderstanding you?
>
> Perhaps you can revisit that question after considering the
> philosophical statements above.

No thanks.  Perhaps you can *answer* that question.

>> In fact, an int object is an int object.  I find that so obvious
>> that it seems odd to have to state it.  For an operation on such
>> an object, a compiler might have to generate code that determines
>> that object's address.  That does not in any sense imply that an
>> int object is "really" a pointer.  You can construct a pointer to
>> an int object, but the pointer and the object it points to are two
>> different things.
>
> We're using pointer in two different senses:  in the sense defined by
> the C standard, and in the sense that an identifier points to
> an object, by definition.  The concept of 'pointer' is implicit to the
> idea of 'object'.  You seem to be confused by the use of pointer to
> refer to anything other than a C pointer object.

Of course I'm confused by your use of the word "pointer" to refer to
things other than actual pointers.  This is comp.lang.c, where we
discuss the C programming language, which is defined by the ISO C
standard, which has an unambiguous meaning for the word "pointer".

And I still don't understand what your other meaning of "pointer" is.
Can you (a) explain exactly what you mean by "pointer", and (b) use a
different word to refer to that concept, to avoid further confusion?

The concept of "pointer" is not implicit in the idea of "object".

> Religions seem to rely on that same kind of confusion to obscure the
> origins and nature of some kinds of religious 'knowledge'.

I'm not interested in discussing religion, at least not here.

>                                                             Moreover,
> thinking about philosophy and ontology is all but outlawed today.

Nonsense.  But philosophy and ontology are not what this newsgroup is
about.  Perhaps you'd be happer in a forum that does discuss philosophy.

Perhaps what you're saying would make sense to someone who has studied
more philosphy than I have.

[snip]

[...]
>> Perhaps.  But an object of pointer-to-struct type is a region
>> of memory holding the address of the struct object.  Why would a
>> compiler allocate and initialize such a pointer object, or generate
>> code to do so, in the absence of C code to take the addrss of the
>> struct object?
>
> Because it is natural to do so.  The fact that your compiler copies
> such structures in assignment contexts (seemingly) one field at a time
> is an artifact of its design.  Another compiler might use a form of
> memcpy(), in which case there would have to be a pointer -- just not
> one that you defined explicitly in your source code.

The generated code I posted upthread was not copying the structure a
field at a time, it was copying it a word at a time.  But the CPU
instructions a compiler chooses to implement an assignment operation
have nothing to do with the conceptual nature of an object.

>> >> Struct objects are very often manipulated via pointers (simulating
>> >> by-reference argument passing, for example), but that's a coding
>> >> convention, not anything inherent to the language.
>> >
>> > Agreed.
>> 
>> So where do these "pointers" you keep talking about come from?
>> In what sense do they exist?

And you haven't answer that question either.

[...]

> I think the philosophical perspective better illustrates what I was
> thinking.  The phase space is referential to a program's execution
> environment, which we generally assume to exist, and hence any object
> in that phase space has an address which is, by definition, a pointer.
>
> I hope this makes things clearer.

Not even a little bit.

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

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

#27651

On 10/24/2012 05:38 PM, Keith Thompson wrote:
...
> ...  This is comp.lang.c, where we
> discuss the C programming language, which is defined by the ISO C
> standard, which has an unambiguous meaning for the word "pointer".

Well - sort of. In different contexts it uses the term "pointer" to mean
either a pointer object or a pointer value. I've found it useful,
particularly in this newsgroup, to be more careful about that
distinction than the standard itself is.

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

#27655

James Kuyper <jameskuyper@verizon.net> writes:
> On 10/24/2012 05:38 PM, Keith Thompson wrote:
> ...
>> ...  This is comp.lang.c, where we
>> discuss the C programming language, which is defined by the ISO C
>> standard, which has an unambiguous meaning for the word "pointer".
>
> Well - sort of. In different contexts it uses the term "pointer" to mean
> either a pointer object or a pointer value. I've found it useful,
> particularly in this newsgroup, to be more careful about that
> distinction than the standard itself is.

That's a good point.  But the standard's use of the term doesn't
extend beyond objects, values, and perhaps expressions and types,
of C pointer types.

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

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

#27653

On 12-10-24 01:20 PM, Steve Thompson wrote:
> On Tue, Oct 23, 2012 at 03:53:21PM -0700, Keith Thompson wrote:
>> Steve Thompson <stevet810@gmail.com> writes:
>>> On Tue, Oct 23, 2012 at 12:26:05PM -0700, Keith Thompson wrote:
>>>> Steve Thompson <stevet810@gmail.com> writes:
>>>>> On Mon, Oct 22, 2012 at 09:06:39PM +0100, Ben Bacarisse wrote:
>>>> [...]
>>>>>> Whatever goes on under the hood (and I'd dispute that 'a' is "really a
>>>>>> pointer") it's much easier to learn a language in its own terms, at
>>>>>> least as far as that's possible.
>>>>>
>>>>> Well, no.  'a' is never a pointer as such in the terms of the language
>>>>> syntax, but its treatment by the compiler internally is nominally
>>>>> equivalent to they way it handles a pointer, with the exception that
>>>>> the language grammar forbids its use in the program text as a pointer.
>>>>
>>>> I don't believe that's true.  Do you have some evidence that it is?
>>>
>>> The distinction is largely moot.  In a practical sense, all variables
>>> have a value which is stored somewhere.  The compiler is making an
>>> explicit use of a pointer when it does something with the value.  The
>>> problem is that "use" in this context may as well be referring to ether
>>> or memory and there's no easy way of knowing which it is.
>>
>> When you say "explicit use of a pointer", do you mean that there's
>> a pointer *object* somewhere, or are you talking about a pointer
>> *value*, also known as an "address"?
>
> I suppose address is the better term, but that does not work for
> registers.
>

I know I should stay out of this. It seems a bit of a train wreck but 
... I strikes me that it does work for registers and points (bad choice 
of word I know) to a fundamental use of the word pointer. A register can 
hold either an address that points to a value or it can hold the value 
itself, should the value be the sort that fits. The same can be said of 
memory locations. They can hold a pointer to some location where a value 
is stored or can hold the value itself. A name in assembly can refer to 
an area of memory that holds value. You can refer to that value using 
the name or you can refer to the address where the memory is.

To me this is the pretty much in keeping with the idea, in C, that <int 
a> will hold a value and <int *a> will hold the address of a value. C 
semantics or otherwise this seems a fairly widely used idiom of speech. 
Is there really a reason to come up with a new way to view it?

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

#27709

On Wed, Oct 24, 2012 at 03:21:29PM -0700, Greg Martin wrote:
> On 12-10-24 01:20 PM, Steve Thompson wrote:
> >On Tue, Oct 23, 2012 at 03:53:21PM -0700, Keith Thompson wrote:
> >>Steve Thompson <stevet810@gmail.com> writes:
> >>>On Tue, Oct 23, 2012 at 12:26:05PM -0700, Keith Thompson wrote:
> >>>>Steve Thompson <stevet810@gmail.com> writes:
> >>>>>On Mon, Oct 22, 2012 at 09:06:39PM +0100, Ben Bacarisse wrote:
> >>>>[...]
> >>>>>>Whatever goes on under the hood (and I'd dispute that 'a' is "really a
> >>>>>>pointer") it's much easier to learn a language in its own terms, at
> >>>>>>least as far as that's possible.
> >>>>>
> >>>>>Well, no.  'a' is never a pointer as such in the terms of the language
> >>>>>syntax, but its treatment by the compiler internally is nominally
> >>>>>equivalent to they way it handles a pointer, with the exception that
> >>>>>the language grammar forbids its use in the program text as a pointer.
> >>>>
> >>>>I don't believe that's true.  Do you have some evidence that it is?
> >>>
> >>>The distinction is largely moot.  In a practical sense, all variables
> >>>have a value which is stored somewhere.  The compiler is making an
> >>>explicit use of a pointer when it does something with the value.  The
> >>>problem is that "use" in this context may as well be referring to ether
> >>>or memory and there's no easy way of knowing which it is.
> >>
> >>When you say "explicit use of a pointer", do you mean that there's
> >>a pointer *object* somewhere, or are you talking about a pointer
> >>*value*, also known as an "address"?
> >
> >I suppose address is the better term, but that does not work for
> >registers.
> >
> 
> I know I should stay out of this. It seems a bit of a train wreck but 
> ... I strikes me that it does work for registers and points (bad choice 
> of word I know) to a fundamental use of the word pointer. A register can 
> hold either an address that points to a value or it can hold the value 
> itself, should the value be the sort that fits. The same can be said of 
> memory locations. They can hold a pointer to some location where a value 
> is stored or can hold the value itself. A name in assembly can refer to 
> an area of memory that holds value. You can refer to that value using 
> the name or you can refer to the address where the memory is.
> 
> To me this is the pretty much in keeping with the idea, in C, that <int 
> a> will hold a value and <int *a> will hold the address of a value. C 
> semantics or otherwise this seems a fairly widely used idiom of speech. 
> Is there really a reason to come up with a new way to view it?

Obviously, the address is a value in the case of a pointer variable.

My meta-point was basically about the fact that (a) English terminology
is overloaded, and not merely in relation to programming, and (b) that
it is useful to think about software, compilers, and programming in
general terms.  There is probably something worthwhile to be had in
examining the philosophy or metaphysics of computer software and
programming.  I think those who reflexively stomp on discussions that
move beyond the confines of a single standard or methodology are in
some way threatened by different ways of thinking about these
subjects.




Regards,

Steve Thompson

-- 
GOTO's are like guns.  Safety is entirely contingent on the user.

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

#27716

Steve Thompson <stevet810@gmail.com> writes:
<snip>
> My meta-point was basically about the fact that (a) English terminology
> is overloaded, and not merely in relation to programming, and (b) that
> it is useful to think about software, compilers, and programming in
> general terms.  There is probably something worthwhile to be had in
> examining the philosophy or metaphysics of computer software and
> programming.  I think those who reflexively stomp on discussions that
> move beyond the confines of a single standard or methodology are in
> some way threatened by different ways of thinking about these
> subjects.

Yes, that's possible, but sometimes Brave New Ideas are just wrong.

Sometimes evidence that they are wrong comes directly from their
proponents, such as when you wrote that:

  "... conceptually 'a' is still a pointer to the data in the specific
  structure identified by 'a'.  I found it very confusing when I was
  learning C."

(This was in the context of a declaration like "struct point {
int x, y, z; } a;".)

It's no wonder that you found it confusing: it's wrong.  It's going to
be a hindrance to learning C to think of 'a' as a pointer when it
isn't one, even "conceptually".

-- 
Ben.

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

#27766

On Fri, Oct 26, 2012 at 01:02:14PM +0100, Ben Bacarisse wrote:
> Steve Thompson <stevet810@gmail.com> writes:
> <snip>
> > My meta-point was basically about the fact that (a) English terminology
> > is overloaded, and not merely in relation to programming, and (b) that
> > it is useful to think about software, compilers, and programming in
> > general terms.  There is probably something worthwhile to be had in
> > examining the philosophy or metaphysics of computer software and
> > programming.  I think those who reflexively stomp on discussions that
> > move beyond the confines of a single standard or methodology are in
> > some way threatened by different ways of thinking about these
> > subjects.
> 
> Yes, that's possible, but sometimes Brave New Ideas are just wrong.
> 
> Sometimes evidence that they are wrong comes directly from their
> proponents, such as when you wrote that:
> 
>   "... conceptually 'a' is still a pointer to the data in the specific
>   structure identified by 'a'.  I found it very confusing when I was
>   learning C."
> 
> (This was in the context of a declaration like "struct point {
> int x, y, z; } a;".)
> 
> It's no wonder that you found it confusing: it's wrong.  It's going to
> be a hindrance to learning C to think of 'a' as a pointer when it
> isn't one, even "conceptually".

I agree that it isn't a pointer in C, but it is an identifier that is
associated with the structure.  With a less restrictive definition of
'pointer', it is and the implementation of its actual use in a program
mimics the semantics of a C pointer, to a certain degree.  Since I am
not using a restrictive definition of 'pointer' in every instance
where I use the term, I think my statements are logically coherent.

If we're going to get hung up on the propriety of specific uses of
language terminology, you are correct in suggesting that this line of
discussion will be a train-wreck.



Regards,

Steve Thompson

-- 
GOTO's are like guns.  Safety is entirely contingent on the user.

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

#27772

Steve Thompson <stevet810@gmail.com> writes:

> On Fri, Oct 26, 2012 at 01:02:14PM +0100, Ben Bacarisse wrote:
>> Steve Thompson <stevet810@gmail.com> writes:
>> <snip>
>> > My meta-point was basically about the fact that (a) English terminology
>> > is overloaded, and not merely in relation to programming, and (b) that
>> > it is useful to think about software, compilers, and programming in
>> > general terms.  There is probably something worthwhile to be had in
>> > examining the philosophy or metaphysics of computer software and
>> > programming.  I think those who reflexively stomp on discussions that
>> > move beyond the confines of a single standard or methodology are in
>> > some way threatened by different ways of thinking about these
>> > subjects.
>> 
>> Yes, that's possible, but sometimes Brave New Ideas are just wrong.
>> 
>> Sometimes evidence that they are wrong comes directly from their
>> proponents, such as when you wrote that:
>> 
>>   "... conceptually 'a' is still a pointer to the data in the specific
>>   structure identified by 'a'.  I found it very confusing when I was
>>   learning C."
>> 
>> (This was in the context of a declaration like "struct point {
>> int x, y, z; } a;".)
>> 
>> It's no wonder that you found it confusing: it's wrong.  It's going to
>> be a hindrance to learning C to think of 'a' as a pointer when it
>> isn't one, even "conceptually".
>
> I agree that it isn't a pointer in C, but it is an identifier that is
> associated with the structure.  With a less restrictive definition of
> 'pointer', it is and the implementation of its actual use in a program
> mimics the semantics of a C pointer, to a certain degree.  Since I am
> not using a restrictive definition of 'pointer' in every instance
> where I use the term, I think my statements are logically coherent.

Can you explain what you found "very confusing" when you were learning
C?  That might explain what your "'a' is conceptually a pointer" model
helps with.  My own view is that, being wrong, it can only obfuscate
matters, but knowing what it helped you with might move things on.

<snip>
-- 
Ben.

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

#27781

Steve Thompson <stevet810@gmail.com> writes:

> On Fri, Oct 26, 2012 at 01:02:14PM +0100, Ben Bacarisse wrote:
>> Steve Thompson <stevet810@gmail.com> writes:
>> <snip>
>> > My meta-point was basically about the fact that (a) English terminology
>> > is overloaded, and not merely in relation to programming, and (b) that
>> > it is useful to think about software, compilers, and programming in
>> > general terms.  There is probably something worthwhile to be had in
>> > examining the philosophy or metaphysics of computer software and
>> > programming.  I think those who reflexively stomp on discussions that
>> > move beyond the confines of a single standard or methodology are in
>> > some way threatened by different ways of thinking about these
>> > subjects.
>> 
>> Yes, that's possible, but sometimes Brave New Ideas are just wrong.
>> 
>> Sometimes evidence that they are wrong comes directly from their
>> proponents, such as when you wrote that:
>> 
>>   "... conceptually 'a' is still a pointer to the data in the specific
>>   structure identified by 'a'.  I found it very confusing when I was
>>   learning C."
>> 
>> (This was in the context of a declaration like "struct point {
>> int x, y, z; } a;".)
>> 
>> It's no wonder that you found it confusing: it's wrong.  It's going to
>> be a hindrance to learning C to think of 'a' as a pointer when it
>> isn't one, even "conceptually".
>
> I agree that it isn't a pointer in C, but it is an identifier that is
> associated with the structure.  With a less restrictive definition of
> 'pointer', it is and the implementation of its actual use in a program
> mimics the semantics of a C pointer, to a certain degree.  Since I am
> not using a restrictive definition of 'pointer' in every instance
> where I use the term, I think my statements are logically coherent.
>
> If we're going to get hung up on the propriety of specific uses of
> language terminology, you are correct in suggesting that this line of
> discussion will be a train-wreck.

"But 'glory' doesn't mean 'a nice knock-down argument'," Alice
objected.

"When I use a word," Humpty Dumpty said, in rather a scornful tone, "it
means just what I choose it to mean—neither more nor less."

"The question is," said Alice, "whether you can make words mean so many
different things."

"The question is," said Humpty Dumpty, "which is to be master -- that's
all."

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

#27797

On Sat, Oct 27, 2012 at 04:36:08PM -0600, Joe Pfeiffer wrote:
> Steve Thompson <stevet810@gmail.com> writes:
> 
> > On Fri, Oct 26, 2012 at 01:02:14PM +0100, Ben Bacarisse wrote:
> >> Steve Thompson <stevet810@gmail.com> writes:
> >> <snip>
> >> > My meta-point was basically about the fact that (a) English terminology
> >> > is overloaded, and not merely in relation to programming, and (b) that
> >> > it is useful to think about software, compilers, and programming in
> >> > general terms.  There is probably something worthwhile to be had in
> >> > examining the philosophy or metaphysics of computer software and
> >> > programming.  I think those who reflexively stomp on discussions that
> >> > move beyond the confines of a single standard or methodology are in
> >> > some way threatened by different ways of thinking about these
> >> > subjects.
> >> 
> >> Yes, that's possible, but sometimes Brave New Ideas are just wrong.
> >> 
> >> Sometimes evidence that they are wrong comes directly from their
> >> proponents, such as when you wrote that:
> >> 
> >>   "... conceptually 'a' is still a pointer to the data in the specific
> >>   structure identified by 'a'.  I found it very confusing when I was
> >>   learning C."
> >> 
> >> (This was in the context of a declaration like "struct point {
> >> int x, y, z; } a;".)
> >> 
> >> It's no wonder that you found it confusing: it's wrong.  It's going to
> >> be a hindrance to learning C to think of 'a' as a pointer when it
> >> isn't one, even "conceptually".
> >
> > I agree that it isn't a pointer in C, but it is an identifier that is
> > associated with the structure.  With a less restrictive definition of
> > 'pointer', it is and the implementation of its actual use in a program
> > mimics the semantics of a C pointer, to a certain degree.  Since I am
> > not using a restrictive definition of 'pointer' in every instance
> > where I use the term, I think my statements are logically coherent.
> >
> > If we're going to get hung up on the propriety of specific uses of
> > language terminology, you are correct in suggesting that this line of
> > discussion will be a train-wreck.
> 
> "But 'glory' doesn't mean 'a nice knock-down argument'," Alice
> objected.
> 
> "When I use a word," Humpty Dumpty said, in rather a scornful tone, "it
> means just what I choose it to mean—neither more nor less."
> 
> "The question is," said Alice, "whether you can make words mean so many
> different things."
> 
> "The question is," said Humpty Dumpty, "which is to be master -- that's
> all."

The underlying issue here is that people take liberty with language
and meaning to a degree that is shocking in some cases.  When I use
the word 'people' as in the previous sentence, am I suggesting a
meaning consistent with 'any member of the species homo sapiens', or
do I have a more restrictive definition in mind?

Your criticism is noted, but I think it is a hyperbole in relation to
the use of the term 'pointer' as in the previous several messages I
wrote in this thread.



Regards,

Steve Thompson

-- 
GOTO's are like guns.  Safety is entirely contingent on the user.

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

#27776

Greg Martin <greg@softsprocket.com> writes:
> On 12-10-24 01:20 PM, Steve Thompson wrote:
> > On Tue, Oct 23, 2012 at 03:53:21PM -0700, Keith Thompson wrote:
> >> Steve Thompson <stevet810@gmail.com> writes:
> >>> On Tue, Oct 23, 2012 at 12:26:05PM -0700, Keith Thompson wrote:
> >>>> Steve Thompson <stevet810@gmail.com> writes:
> >>>>> On Mon, Oct 22, 2012 at 09:06:39PM +0100, Ben Bacarisse wrote:
> >>>> [...]
> >>>>>> Whatever goes on under the hood (and I'd dispute that 'a' is "really a
> >>>>>> pointer") it's much easier to learn a language in its own terms, at
> >>>>>> least as far as that's possible.
> >>>>>
> >>>>> Well, no.  'a' is never a pointer as such in the terms of the language
> >>>>> syntax, but its treatment by the compiler internally is nominally
> >>>>> equivalent to they way it handles a pointer, with the exception that
> >>>>> the language grammar forbids its use in the program text as a pointer.
> >>>>
> >>>> I don't believe that's true.  Do you have some evidence that it is?
> >>>
> >>> The distinction is largely moot.  In a practical sense, all variables
> >>> have a value which is stored somewhere.  The compiler is making an
> >>> explicit use of a pointer when it does something with the value.  The
> >>> problem is that "use" in this context may as well be referring to ether
> >>> or memory and there's no easy way of knowing which it is.
> >>
> >> When you say "explicit use of a pointer", do you mean that there's
> >> a pointer *object* somewhere, or are you talking about a pointer
> >> *value*, also known as an "address"?
> >
> > I suppose address is the better term, but that does not work for
> > registers.
> >
> 
> I know I should stay out of this. It seems a bit of a train wreck but
> ... I strikes me that it does work for registers and points (bad
> choice of word I know) to a fundamental use of the word pointer. A
> register can hold either an address that points to a value or it can
> hold the value itself, should the value be the sort that fits.

Not always. An architecture can have registers that may only be used
as addresses and others which may not be used as addresses, there's no
obligation for all registers to be used for all purposes.

Phil
-- 
Regarding TSA regulations:
How are four small bottles of liquid different from one large bottle?
Because four bottles can hold the components of a binary liquid explosive,
whereas one big bottle can't. -- camperdave responding to MacAndrew on /.

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

#27778

On 12-10-27 12:42 PM, Phil Carmody wrote:
 > Greg Martin <greg@softsprocket.com> writes:

 >>
 >> I know I should stay out of this. It seems a bit of a train wreck but
 >> ... I strikes me that it does work for registers and points (bad
 >> choice of word I know) to a fundamental use of the word pointer. A
 >> register can hold either an address that points to a value or it can
 >> hold the value itself, should the value be the sort that fits.
 >
 > Not always. An architecture can have registers that may only be used
 > as addresses and others which may not be used as addresses, there's no
 > obligation for all registers to be used for all purposes.
 >
 > Phil
 >

Quite true, I should have stipulated general registers as well since 
some registers aren't used for either.

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

#27779

"Greg Martin" <greg@softsprocket.com> wrote in message 
news:9oYis.2124$zu4.150@newsfe14.iad...
>
> On 12-10-27 12:42 PM, Phil Carmody wrote:
> > Greg Martin <greg@softsprocket.com> writes:
>

> >> A
> >> register can hold either an address that points to a value or it can
> >> hold the value itself, should the value be the sort that fits.
> >
> > Not always. An architecture can have registers that may only be used
> > as addresses and others which may not be used as addresses, there's no
> > obligation for all registers to be used for all purposes.
> >
> > Phil
> >
>
> Quite true, I should have stipulated general registers as well since some 
> registers aren't used for either.

Addresses of variables were also mentioned. When these are register 
variables, that means taking the address of a register, rather than a 
register simply containing an address.

Register addresses are unusual. In any case I doubt whether C allows them.

-- 
Bartc 

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

#27783

"BartC" <bc@freeuk.com> writes:
[...]
> Register addresses are unusual. In any case I doubt whether C allows them.

It doesn't.  N1370 6.5.3.2:

    Constraints

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

Not that an object declared with the "register" keyword may or may
not actually be stored in a CPU register; likewise for an object
declared *without* the "register" keyword.

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

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

#27784

Keith Thompson <kst-u@mib.org> writes:
> "BartC" <bc@freeuk.com> writes:
> [...]
>> Register addresses are unusual. In any case I doubt whether C allows them.
>
> It doesn't.  N1370 6.5.3.2:
>
>     Constraints
>
>   1 The operand of the unary & operator shall be either a function
>     designator, the result of a [] or unary * operator, or an lvalue
>     that designates an object that is not a bit-field and is not
>     declared with the register storage-class specifier.
>
> Not that an object declared with the "register" keyword may or may
> not actually be stored in a CPU register; likewise for an object
> declared *without* the "register" keyword.

Sorry, I meant *Note* than an object ...

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

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

#27785

Keith Thompson <kst-u@mib.org> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> "BartC" <bc@freeuk.com> writes:
>> [...]
>>> Register addresses are unusual. In any case I doubt whether C allows them.
>>
>> It doesn't.  N1370 6.5.3.2:
>>
>>     Constraints
>>
>>   1 The operand of the unary & operator shall be either a function
>>     designator, the result of a [] or unary * operator, or an lvalue
>>     that designates an object that is not a bit-field and is not
>>     declared with the register storage-class specifier.
>>
>> Not that an object declared with the "register" keyword may or may
>> not actually be stored in a CPU register; likewise for an object
>> declared *without* the "register" keyword.
>
> Sorry, I meant *Note* than an object ...

I meant "Note *that* an object ..."

*sigh*

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

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

#27656

Steve Thompson <stevet810@gmail.com> writes:
[...]

Steve, it's been brought to my attention that you're posting under the
same e-mail address used by "Uncle Steve".  I presume you're the same
person.  I killfiled you some time ago for being rude and vulgar
(<https://groups.google.com/forum/#!msg/comp.lang.c/jQdPYdBJ7RI/tl8ke_nkyjAJ>
in the unlikely event that anyone cares).

I've replied to recent articles only because you're now posting under a
different name, and my newsreader didn't notice.

This recent discussion hasn't been constructive anyway, and I won't
continue it unless I see a very good reason to do so.  (Others will do
as they choose.)

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

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

#27663

On Wed, Oct 24, 2012 at 04:46:04PM -0700, Keith Thompson wrote:
> Steve Thompson <stevet810@gmail.com> writes:
> [...]
> 
> Steve, it's been brought to my attention that you're posting under the
> same e-mail address used by "Uncle Steve".  I presume you're the same
> person.  I killfiled you some time ago for being rude and vulgar
> (<https://groups.google.com/forum/#!msg/comp.lang.c/jQdPYdBJ7RI/tl8ke_nkyjAJ>
> in the unlikely event that anyone cares).

Horrors!  My precious vulgar language has be censored by Google
groups.  Posix threads, or rather the API, still sucks.
 
> I've replied to recent articles only because you're now posting under a
> different name, and my newsreader didn't notice.

I can change it back to Uncle Steve if you'd prefer.  I doubt you
would notice the difference.
 
> This recent discussion hasn't been constructive anyway, and I won't
> continue it unless I see a very good reason to do so.  (Others will do
> as they choose.)

You were mostly ignoring what I was writing anyways.  You seem to hide
behind the C standard as if it is all that matters to a hermetically
sealed newsgroup, despite the fact that the standard does not live in
a vacuum.  I will make my response to your previous reply shortly.
You can decide what to do with it at that point.



Regards,

Steve Thompson

-- 
GOTO's are like guns.  Safety is entirely contingent on the user.

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

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

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

csiph-web