nasm-devel

[Nasm-devel] on fix for BR3414012

[Cyrill G. <gor...@gm...>]

Guys, I've just pushed out a fix for BR3414012 but note it
changes the preprocessor workflow a bit, in particular the
constructions like

 | %ifdef
 | %endif

are not longer valid (note the absence of variables names there).
I believe the same trailing space problem take a place for %ifenv
term (and bare %ifenv/%endif as well) but I didn't fixed it yet.

What do you think?

	Cyrill

Re: [Nasm-devel] on fix for BR3414012

[Cyrill G. <gor...@gm...>]

On Sat, Oct 01, 2011 at 06:21:49PM -0500, Keith Kanios wrote:
> If I understand you correctly -- i.e.
> for(skip_white_(tline),tline,skip_white_(tline)) -- then that should
> be acceptable. %ifdef should never be allowed to be blank and thus
> should throw an error.
> 
> In short, yes, being consistent is more important than being concise.
> 
> Just my 2 ¢.
> 
> -Keith
> 

Yes, exactly. Thanks Keith!

	Cyrill

Re: [Nasm-devel] on fix for BR3414012

[Cyrill G. <gor...@gm...>]

On Sun, Oct 02, 2011 at 08:20:17AM +0400, Cyrill Gorcunov wrote:
...
> 
> Yes, exactly. Thanks Keith!
> 

Btw, while were looking into this bug I found an interesting
thing -- if some macro expands to nothing we don't return empy
term but TOK_WHITESPACE instead. This is wrong. (For this reason
x264 codec is not compilable with nasm.) This term should be
a composite entity and has some additional info such as 'ok,
this term is whitespace due to exponasion to empty line' and
in case if there

	TOK_ID %+ TOK_WHITESPACE_DUE_TO_EXPANSION %+ TOK_ID

we would drop TOK_WHITESPACE_DUE_TO_EXPANSION and simply join
TOK_ID+TOK_ID.

Not sure how to make it in better way at moment though.

	Cyrill

Re: [Nasm-devel] on fix for BR3414012

[H. P. A. <hp...@zy...>]

On 10/02/2011 05:10 AM, Cyrill Gorcunov wrote:
> 
> Btw, while were looking into this bug I found an interesting
> thing -- if some macro expands to nothing we don't return empy
> term but TOK_WHITESPACE instead. This is wrong. (For this reason
> x264 codec is not compilable with nasm.) This term should be
> a composite entity and has some additional info such as 'ok,
> this term is whitespace due to exponasion to empty line' and
> in case if there
> 
> 	TOK_ID %+ TOK_WHITESPACE_DUE_TO_EXPANSION %+ TOK_ID
> 
> we would drop TOK_WHITESPACE_DUE_TO_EXPANSION and simply join
> TOK_ID+TOK_ID.
> 
> Not sure how to make it in better way at moment though.
> 

What if we let %+ absorb surrounding TOK_WHITESPACE, so the above
composites correctly?

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [Nasm-devel] on fix for BR3414012

[Cyrill G. <gor...@gm...>]

On Sun, Oct 02, 2011 at 10:55:22AM -0700, H. Peter Anvin wrote:
...
> 
> What if we let %+ absorb surrounding TOK_WHITESPACE, so the above
> composites correctly?
> 
> 	-hpa
> 

Yeah, good idea, i'll check on the week.

	Cyrill