flat assembler
Message board for the users of flat assembler.

Index > Main > [fasmg] namespace traversal bug or ?

Author
Thread Post new topic Reply to topic
sylware



Joined: 23 Oct 2020
Posts: 81
Location: Marseille/France
sylware
Here is a code sample:
Code:
include 'format/format.inc'
format.elf64
use64
section '.text' executable writeable align 16
_start:
    mov rax, [a.b.c.mydata]
section '.data' writeable align 64
namespace a
        c: rq 1
        namespace b
                namespace c
                        mydata: rq 1
                end namespace
        end namespace
end namespace
    


I get: "Error: symbol 'a.b.c.mydata' is undefined or out of scope"

but if I comment out: ";c:rq 1"

It seems to assemble fine.

What do I still not understand about namespace traversal? Sad
Post 01 Oct 2021, 17:48
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7938
Location: Kraków, Poland
Tomasz Grysztar
When "c" is not defined, it defaults to symbol in current namespace, so "namespace c" looks up the namespace of "a.b.c" - but when you have "c" symbol defined (with "c:") at another level - in this case as "a.c", you end up switching to it instead. The symbol that gets defined then is "a.c.mydata".

An important thing to note is that NAMESPACE directive does not create the namespace, it just switches temporarily to a namespace that it finds through the provided identifier. You do not nest NAMESPACE blocks to create a similarly nested tree, each of them just switches the base namespace and then switches back.

It may help to think of "namespace c"/"end namespace" block as meaning do something in namespace called c, not make a namespace c here. It refers to an existing symbol (though when none is found, it picks one in current namespace, even if undefined).

Therefore, if you need to reliably make a tree of nested namespaces, you should ensure to always have them specified through defined symbols, for example:
Code:
a: namespace a
        c: rq 1
        b: namespace b
                c: namespace c
                        mydata: rq 1
                end namespace
        end namespace
end namespace    
Perhaps it would have been less confusing if I named this directive NAMESPACEOF instead of plain NAMESPACE. I could still introduce that as a synonym.
Post 01 Oct 2021, 21:17
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18222
Location: In your JS exploiting you and your system
revolution
Tomasz Grysztar wrote:
Perhaps it would have been less confusing if I named this directive NAMESPACEOF instead of plain NAMESPACE. I could still introduce that as a synonym.
Maybe: GOTONAMESPACEOFORFAKEANEWONEHERE
Post 01 Oct 2021, 22:38
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3307
Location: vpcmipstrm
bitRAKE
The brief name for the directive makes sense in light of the overall philosophy used - which is analogous with assembly language programming. Directives tend to do what is sufficient and not too much as to be overly restrictive, imho.
Post 02 Oct 2021, 14:03
View user's profile Send private message Visit poster's website Reply with quote
sylware



Joined: 23 Oct 2020
Posts: 81
Location: Marseille/France
sylware
@Tomasz okay! My mental picture of fasmg objects is improving. Then if the "in-between" namespaces do not exist, "where" is going the definition then? The identifier is actually "a.b.c.mydata" in the "top" namespace?

@others: usually, it is just a matter of tuning to the manual.
Post 02 Oct 2021, 15:15
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7938
Location: Kraków, Poland
Tomasz Grysztar
sylware wrote:
Then if the "in-between" namespaces do not exist, "where" is going the definition then?
All the namespaces always exist, the only thing that changes is your ability to refer to them. You specify a namespace by pointing to a symbol, and this may be a symbol which is anywhere in the hierarchy, as long as you are able to refer to it somehow.

And - by design - you can refer to symbols only in relative terms, which allows to encapsulate any module in a way that is not apparent from within. When you write something like "a.b.c", it is never absolute, it is anchored at the nearest "a" that is defined and visible to you (and if no "a" is defined anywhere, it is assumed to mean the one in the current namespace, even if it never gets defined).
Post 02 Oct 2021, 17:31
View user's profile Send private message Visit poster's website Reply with quote
sylware



Joined: 23 Oct 2020
Posts: 81
Location: Marseille/France
sylware
I got several times the strong encapsulation feature (I never did expect something else to say the least).

Then, what are the general rules for hierarchical identifiers? For instance "a.b.c.d". I guess it will start from "a"
: if no instance of expression class with such symbol in current namespace is found , it will start to walk upward the namespaces until one is found. If one is found, it will then be used as an "anchor" to walk downward the namespaces, but if b does not have any instance of expression class associated with it in namespace a, I'll get an error, right? Because it seems I can walk downward the namespace hierarchy without the need to have an instance of expression class associated with each symbol at each depth. Wrong?
Post 02 Oct 2021, 20:05
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7938
Location: Kraków, Poland
Tomasz Grysztar
sylware wrote:
Then, what are the general rules for hierarchical identifiers? For instance "a.b.c.d". I guess it will start from "a"
: if no instance of expression class with such symbol in current namespace is found , it will start to walk upward the namespaces until one is found. If one is found, it will then be used as an "anchor" to walk downward the namespaces, but if b does not have any instance of expression class associated with it in namespace a, I'll get an error, right?
No, the presence of defined symbol only matters for the "anchor", the first name. The dot always implies the direct relationship, so "a.b" is always going to mean "b" in the namespace of "a" (whichever "a" ends up being used), even if "b" symbol is never defined there.
Post 02 Oct 2021, 21:55
View user's profile Send private message Visit poster's website Reply with quote
sylware



Joined: 23 Oct 2020
Posts: 81
Location: Marseille/France
sylware
Allright!

In the light of this thread, where in the manual those topics are explicited?
Because I did read a few times the manual, but it is so dense, I always manage to forget where to look and I end up posting on the message board.
Post 03 Oct 2021, 15:26
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7938
Location: Kraków, Poland
Tomasz Grysztar
Small correction to my previous post: the definition of symbol may still matter for the name after the dot (like "b" in the example) if there is matching case-insensitive symbol defined, but no case-sensitive one. For example:
Code:
a.B?:
dd a.b.c ; looks for a.B?.c, as it first finds a.B? namespace and then looks for c in there    
Code:
a.b:
a.B?:
dd a.b.c ; looks for a.b.c, case-sensitive takes precedence    
(You can see it in the error messages if you try to assemble these snippets.)

sylware wrote:
In the light of this thread, where in the manual those topics are explicited?
Because I did read a few times the manual, but it is so dense, I always manage to forget where to look and I end up posting on the message board.
It is almost exclusively discussed in chapter 2. And yes, it is very dense, because the entire main manual was written in such dense way - this is why I also added auxiliary documentation to provide more examples with in-depth discussion. Probably this topic also deserves such treatment, as another Q&A-style section there.
Post 03 Oct 2021, 16:40
View user's profile Send private message Visit poster's website Reply with quote
sylware



Joined: 23 Oct 2020
Posts: 81
Location: Marseille/France
sylware
I have to admit, I kind of dropped the case sensitive/unsensitive handling support and went full case sensitive.

I am still not decided about dropping the classic macro language to go full calm instructions. I wonder how much dropping the classic macro language (and now the case sensitive/unsensitive handling mechanics) would simplify the fasmg "specs" (implementation internals).
Post 03 Oct 2021, 21:15
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.