Up to date Windows 10. FB 1.08.1
I reduced a problem to the following and tried a couple of things. The compiler aborts if I do the following, no error message just stops working and Windows tries to report this to Microsoft. (do not know why font changes?)
#macro advance(label,args...)
#Print __FB_ARG_EXTRACT__(0,args)
#Print __FB_ARG_EXTRACT__(1,args)
#EndMacro
advance()
advance(a)
advance(a,b)
advance(a,b,c)
Then I try
#macro advance(label,args...)
#Print __FB_ARG_EXTRACT__(0,args)
#Print __FB_ARG_EXTRACT__(1,args)
#EndMacro
'advance()
advance(a)
advance(a,b)
advance(a,b,c)
Still an error abort
#macro advance(label,args...)
#Print __FB_ARG_EXTRACT__(0,args)
#Print __FB_ARG_EXTRACT__(1,args)
#EndMacro
'advance()
advance(a,)
advance(a,b)
advance(a,b,c)
Works without any errors or aborts. - What it should do
If I want to call the macro with only the first (required agrument) and no optional arguments, is the final comma really necessary?
I tried #Macro advance(args...)
But
advance()
advance(a,)
advance(a,b)
advance(a,b,c)
Still gives a compiler abort
Documentation states.
If the requested index value refers to an argument that does not exist in the supplied argument list (index value too large), nothing is returned.
In either case a compiler error should be generated and not have the compiler abort instead.
To summarize this bug concerning:
__FB_ARG_EXTRACT__(index, args ...)The compiler aborts when 'args ...' is not provided at all (but the comma is there):
__FB_ARG_EXTRACT__(index,)For example:
__FB_ARG_EXTRACT__(0,)induces:
Aborting due to runtime error 12 ("segmentation violation" signal)
from the compiler.
Last edit: fxm (freebasic.net) 2021-09-27
I do not know if this is the correct way to respond. But thank you for letting me know why the compiler aborted.
Will this compiler abort be fixed to generate an error message verses aborting?
I would personly vote to fix it by allowing the compiler to set args to no arguments for the
macro advance(label,args)
for a call of
advanceadvance(lab)advance(lab,)
Thank you for your consideration.
Wally & Julie Gazdzik (retired and loving it)
To summarize this bug concerning: FB_ARG_EXTRACT (index, args ...)
The compiler aborts when 'args ...' is not provided:
FB_ARG_EXTRACT (index,)
For example:
FB_ARG_EXTRACT(0,)
induces
Aborting due to runtime error 12 ("segmentation violation" signal)
from the compiler.
[bugs:#939] FB_ARG_EXTRACT causes compiler abort ???
Status: open
Labels: FB_ARG_EXTRACT Error
Created: Mon Sep 27, 2021 12:20 AM UTC by Wally Gazdzik
Last Updated: Mon Sep 27, 2021 12:20 AM UTC
Owner: nobody
Up to date Windows 10. FB 1.08.1
I reduced a problem to the following and tried a couple of things. The compiler aborts if I do the following, no error message just stops working and Windows tries to report this to Microsoft. (do not know why font changes?)
macro advance(label,args...)
Print FB_ARG_EXTRACT(0,args)
Print FB_ARG_EXTRACT(1,args)
EndMacro
advance()
advance(a)
advance(a,b)
advance(a,b,c)
Then I try
macro advance(label,args...)
Print FB_ARG_EXTRACT(0,args)
Print FB_ARG_EXTRACT(1,args)
EndMacro
'advance()
advance(a)
advance(a,b)
advance(a,b,c)
Still an error abort
macro advance(label,args...)
Print FB_ARG_EXTRACT(0,args)
Print FB_ARG_EXTRACT(1,args)
EndMacro
'advance()
advance(a,)
advance(a,b)
advance(a,b,c)
Works without any errors or aborts. - What it should do
If I want to call the macro with only the first (required agrument) and no optional arguments, is the final comma really necessary?
I tried #Macro advance(args...)
But
advance()
advance(a,)
advance(a,b)
advance(a,b,c)
Still gives a compiler abort
Documentation states.
If the requested index value refers to an argument that does not exist in the supplied argument list (index value too large), nothing is returned.
In either case a compiler error should be generated and not have the compiler abort instead.
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/fbc/bugs/939/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Related
Bugs:
#939Diff:
Code tags added in opening post.
Fixed in fbc 1.09.0
commit: [6c6b30f0e46d2ef895ac598ecde9dad66bfa94a3]
Internally compiler fault was due to NULL pointer use on an empty argument list.
New tests added to test suite.
Related
Commit: [6c6b30]
Thank you for fixing this. I look forward to the 1.09 release.
Wally & Julie Gazdzik (retired and loving it)
[bugs:#939] FB_ARG_EXTRACT causes compiler abort ???
Status: closed
Labels: FB_ARG_EXTRACT Error
Created: Mon Sep 27, 2021 12:20 AM UTC by Wally Gazdzik
Last Updated: Mon Sep 27, 2021 11:18 PM UTC
Owner: nobody
Up to date Windows 10. FB 1.08.1
I reduced a problem to the following and tried a couple of things. The compiler aborts if I do the following, no error message just stops working and Windows tries to report this to Microsoft. (do not know why font changes?)
macro advance(label,args...)
Print FB_ARG_EXTRACT(0,args)
Print FB_ARG_EXTRACT(1,args)
EndMacro
advance()
advance(a)
advance(a,b)
advance(a,b,c)
Then I try
macro advance(label,args...)
Print FB_ARG_EXTRACT(0,args)
Print FB_ARG_EXTRACT(1,args)
EndMacro
'advance()
advance(a)
advance(a,b)
advance(a,b,c)
Still an error abort
macro advance(label,args...)
Print FB_ARG_EXTRACT(0,args)
Print FB_ARG_EXTRACT(1,args)
EndMacro
'advance()
advance(a,)
advance(a,b)
advance(a,b,c)
Works without any errors or aborts. - What it should do
If I want to call the macro with only the first (required agrument) and no optional arguments, is the final comma really necessary?
I tried #Macro advance(args...)
But
advance()
advance(a,)
advance(a,b)
advance(a,b,c)
Still gives a compiler abort
Documentation states.
If the requested index value refers to an argument that does not exist in the supplied argument list (index value too large), nothing is returned.
In either case a compiler error should be generated and not have the compiler abort instead.
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/fbc/bugs/939/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Related
Bugs:
#939