Complains about a HANDLED exception !

Question

People,
I am still getting the ORA -01858 error in reports 2.5 on a valid trig on a p/form item. We pass params from reps2.5 p/form facility here. Can anyone suggesy anything please? Get ready, here's my code:
function RSEQValidTrigger return boolean is
cursor chek_rec is
select 'X'
from SSBOSS.SSBKCDEP_LOG
where rseqno = :rseq
and locn_id = :area
and dseqno between :dseq1 and :dseq2;
dateformaterr EXCEPTION;
pragma EXCEPTION_INIT(dateformaterr,-1861);
dateformaterr2 EXCEPTION;
pragma EXCEPTION_INIT(dateformaterr2,-1858);
dateformaterr3 EXCEPTION;
pragma EXCEPTION_INIT(dateformaterr3,-1847);
v_dummy varchar2(1) := null;
begin
if :dseq1 is not null
and :dseq2 is not null then
if :rseq is not null then
open chek_rec;
fetch chek_rec into v_dummy;
if v_dummy = 'X' then
null;
close chek_rec;
return (TRUE);
else
srw.message(0004,'Receipt number'||' '||to_char(:rseq)
                              ||' '||'does not exist for location'
                              ||' '||:area
                              ||' '||'for range'
                              ||' '||to_char(:dseq1)
                              ||' '||'to'
                              ||' '||to_char(:dseq2)||'!');
close chek_rec;
return (false);
end if;
else
return (TRUE);
end if;
else
return (TRUE);
end if;
exception
when dateformaterr then
srw.message(0006,'Cancellation date must be of format ''DD-MON-YYYY'' ''!''');
return (false);
when dateformaterr2 then
srw.message(0006,'Cancellation date must be of format ''DD-MON-YYYY'' ''!''');
return (false);
when dateformaterr3 then
srw.message(0006,'Cancellation date must be of format ''DD-MON-YYYY'' ''!''');
return (false);
end;
Please be assured that I appreciate yourpreciious and valuable time.
Arios
nik.

Answer 1

After reading the source code for the tool it turns out that it just doesn't handle textual labels correctly in intel_syntax mode. The intel parser logic will interpret all previously defined symbols as a 'memory' operand and then refuse to accept the jmp instruction because it requires a 'displacement' operand.
The forward jumps happen to work because the type of an operand with undefined symbols are resolved in the backend which is shared for both intel and att modes. At that point all labels in the source code have been defined so it can correctly distinguish between a memory and displacement operand.
The good news is that I did find a way to get the get the assembler to jump backwards correctly by using local labels as described in 'Mac OS X Assembler Reference' and the latest GAS documentation. You can specify numeric labels and jump to them using #b and #f. The intel parser explicitly checks for this suffix and treats it as a displacement.
<pre>
.intel_syntax
fooA: jmp wtfA
0: wtfA: ret
barA: jmp 0b
</pre>
I'll be putting in a bug report for this one since it is not fixed in cctools-750~70.
Thanks.