question about Qnil representation

question about Qnil representation

[Troy Hinckley]

[-- Attachment #1: Type: text/plain, Size: 369 bytes --]

I have been reading through the C source to try and learn it and understand it better. I saw in Changeling.13 an entry From Paul Eggert on 2015-01-05 with “Use 0 for Qnil” As a fix for Bug#15880. How does this work in practice? It looks like symbols are just pointers, but 0 would not be a valid pointer. I don’t see any special code for handling the null case.

[-- Attachment #2: Type: text/html, Size: 543 bytes --]

Re: question about Qnil representation

[Eli Zaretskii]

> Date: Wed, 26 Oct 2022 09:40:30 -0600
> From: Troy Hinckley <troyhinckley@gmail.com>
> 
> I have been reading through the C source to try and learn it and understand it better. I saw in Changeling.13 an
> entry From Paul Eggert on 2015-01-05 with “Use 0 for Qnil” As a fix for Bug#15880. How does this work in
> practice? It looks like symbols are just pointers, but 0 would not be a valid pointer. I don’t see any special code
> for handling the null case. 

Symbols are not pointers, they have the same C type as any other
Lisp_Object.  If Lisp_Object is represented by an integer number, then
zero is a valid integer number as well.

Re: question about Qnil representation

[Troy Hinckley]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

Sure, but it reinterprets the integer as a *Lisp_Symbol to get at the actual struct correct? Or am I misunderstanding how this works?
On Oct 26, 2022, 10:00 AM -0600, Eli Zaretskii <eliz@gnu.org>, wrote:
> > Date: Wed, 26 Oct 2022 09:40:30 -0600
> > From: Troy Hinckley <troyhinckley@gmail.com>
> >
> > I have been reading through the C source to try and learn it and understand it better. I saw in Changeling.13 an
> > entry From Paul Eggert on 2015-01-05 with “Use 0 for Qnil” As a fix for Bug#15880. How does this work in
> > practice? It looks like symbols are just pointers, but 0 would not be a valid pointer. I don’t see any special code
> > for handling the null case.
>
> Symbols are not pointers, they have the same C type as any other
> Lisp_Object. If Lisp_Object is represented by an integer number, then
> zero is a valid integer number as well.
>

[-- Attachment #2: Type: text/html, Size: 1341 bytes --]

Re: question about Qnil representation

[Eli Zaretskii]

> Date: Wed, 26 Oct 2022 10:04:47 -0600
> From: Troy Hinckley <troyhinckley@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> Sure, but it reinterprets the integer as a *Lisp_Symbol to get at the actual struct correct?

Like every other Lisp_Object does, yes.

So what is the problem you see with Qnil?  And how is that different from, say Qt?

Re: question about Qnil representation

[Po Lu]

Troy Hinckley <troyhinckley@gmail.com> writes:

> Sure, but it reinterprets the integer as a *Lisp_Symbol to get at the
> actual struct correct?

No, Emacs never reinterprets Lisp_Objects, as they have a tag.

> Or am I misunderstanding how this works?

Yes.  There are several tagging schemes used to associate Lisp_Objects
with their types.  Usually, if a platform can provide the proper
alignment requirements, the least significant 3 bits of the word type
(configured at build-time) are used to a tag containing type
information.  After the tag bit is removed, Lisp_Objects are either
pointers to the corresponding Lisp_Foo struct, integers, or symbols,
which are actually offsets from the start of the auto-generated
`lispsym' array in global.h.  The first element of that array is nil,
and the tag bit for the symbol type is 0, so XSYMBOL naturally returns
the correct `nil' Lisp_Symbol for the integer 0.

Re: question about Qnil representation

[Matt Armstrong]

Troy Hinckley <troyhinckley@gmail.com> writes:

> but 0 would not be a valid pointer.

I am a confused by this.  0 is a valid value for a C pointer.  This is
what NULL is, etc.  You must not dereference it, but it is a valid
value.

Re: question about Qnil representation

[Troy Hinckley]

[-- Attachment #1: Type: text/plain, Size: 956 bytes --]

Clearly I am doing a poor job explaining my question.

Let me try again. As I understand it, every Symbol is an instance if Lisp_Symbol. The Lisp_Object is an integer that can represent multiple types with tags defined by Lisp_Type. If the tag is 0, then the type is a symbol. In that case you would treat the rest of the bytes in the Lisp_Object as pointer to a Lisp_Symbol instance. However if the symbol nil is defined as 0, then it is not a pointer to anything. How then do you access that symbol? Is there special case code to handle the null pointer?

I hope that question makes more sense. Let me know where my understanding is wrong.
On Oct 26, 2022, 10:16 AM -0600, Matt Armstrong <matt@rfc20.org>, wrote:
> Troy Hinckley <troyhinckley@gmail.com> writes:
>
> > but 0 would not be a valid pointer.
>
> I am a confused by this. 0 is a valid value for a C pointer. This is
> what NULL is, etc. You must not dereference it, but it is a valid
> value.

[-- Attachment #2: Type: text/html, Size: 1447 bytes --]

Re: question about Qnil representation

[Eli Zaretskii]

> Date: Wed, 26 Oct 2022 10:22:54 -0600
> From: Troy Hinckley <troyhinckley@gmail.com>
> 
> Let me try again. As I understand it, every Symbol is an instance if Lisp_Symbol. The Lisp_Object is an
> integer that can represent multiple types with tags defined by Lisp_Type. If the tag is 0, then the type is a
> symbol. In that case you would treat the rest of the bytes in the Lisp_Object as pointer to a Lisp_Symbol
> instance. However if the symbol nil is defined as 0, then it is not a pointer to anything. How then do you access
> that symbol? Is there special case code to handle the null pointer?

See make_lisp_symbol and builtin_lisp_symbol, and I think you will
understand what's going on here.  Also see the value stored in
lispsym[0].

Re: question about Qnil representation

[Troy Hinckley]

[-- Attachment #1: Type: text/plain, Size: 970 bytes --]

Ah, thank you. So it is not a pointer but an index. Is lispsym array resizable or is there a static limit to the number of symbols?
On Oct 26, 2022, 10:45 AM -0600, Eli Zaretskii <eliz@gnu.org>, wrote:
> > Date: Wed, 26 Oct 2022 10:22:54 -0600
> > From: Troy Hinckley <troyhinckley@gmail.com>
> >
> > Let me try again. As I understand it, every Symbol is an instance if Lisp_Symbol. The Lisp_Object is an
> > integer that can represent multiple types with tags defined by Lisp_Type. If the tag is 0, then the type is a
> > symbol. In that case you would treat the rest of the bytes in the Lisp_Object as pointer to a Lisp_Symbol
> > instance. However if the symbol nil is defined as 0, then it is not a pointer to anything. How then do you access
> > that symbol? Is there special case code to handle the null pointer?
>
> See make_lisp_symbol and builtin_lisp_symbol, and I think you will
> understand what's going on here. Also see the value stored in
> lispsym[0].
>

[-- Attachment #2: Type: text/html, Size: 1446 bytes --]

Re: question about Qnil representation

[Stefan Monnier]

> Ah, thank you. So it is not a pointer but an index.

Not really: it's a pointer that's offset by just the right amount that
it ends up being 0 in the case of the pointer to Qnil.


        Stefan

Re: question about Qnil representation

[Eli Zaretskii]

> Date: Wed, 26 Oct 2022 12:46:39 -0600
> From: Troy Hinckley <troyhinckley@gmail.com>
> Cc: emacs-devel@gnu.org, matt@rfc20.org
> 
> Ah, thank you. So it is not a pointer but an index. Is lispsym array resizable or is there a static limit to the
> number of symbols?

The built-in symbols are in a static array.  Its size is computed at
build time, when the globals.h header file is produced, and it is
large enough to hold all the DEFSYM symbols defined in the C sources.

Re: question about Qnil representation

[Po Lu]

Troy Hinckley <troyhinckley@gmail.com> writes:

> Ah, thank you. So it is not a pointer but an index. Is lispsym array
> resizable or is there a static limit to the number of symbols?

It is a static array, but we don't actually care about its bounds; it's
only used to provide the base address to which the offset in a tagged
symbol is added.