Re: [Nasm-devel] Externdefs

[<lar...@te...>]

Thanks for the reply.

>> This functionality is definitely important.

I had to create a new fork as the master branch changed to much. Still I
was able to do the same patch as before.

http://repo.or.cz/nasm/externdefs2.git

Debug output is not yet removed.

>> However, I have a few problems with this patch, none of which should 
>> be
>> a huge deal to address:

>> 1. You are including stylistic changes in the patch.  Those should be
>>   separate patches.  Even if you change defines to enums (useful)
>>   please leave them capitalized to indicate them as constants.

No more due to branching from current master.

>> 2. Please remove stealth whitespace before committing.

I did.

>> 3. I would like "extern" to provide this functionality in conjunction
>>   with "global" (in other words, "extern" is ignored if the symbol is
>>   locally defined; we should probably issue a warning if an "extern"
>>   symbol is subsequently defined as a local; however, there are some
>>   valid use cases.)

This maybe needs a code example to define the exact behavior. I read it 
like this:

[extern func]  ; becomes global as soon as func was found

func:
    ret

>> 4. Right now we don't issue any kind of diagnostic if a symbol is
>>   referenced in a "global" directive but then never defined nor
>>   accessed in the local module; the symbol is simply omitted from the
>>   output.  We could just redefine "global" to do what your 
>> "externdefs"
>>   directive does, and at least I can't find a reason why we shouldn't
>>   (but I'm more than willing to listen, I can certainly be wrong.)

This addition would be reasonable behavior.

>> What do you think?

I think this patch is already closer to an ugly hack than a nice patch. 
At the
moment there is no guarantee that it doesn't break any existing code due 
to the
small change in the code that handles extern declarations.
Also there is a warning message which reads

    GLOBAL directive after symbol definition is an experimental feature

for some reason.

With this in mind I would not change the current behavior of *old* 
directives as
code may depend on this specific behavior. It's always the same game.

Everything else would require much more work and knowledge of the 
internals of
label and symbol definitions of nasm to do it by myself.