On 06-03-2011 14:21:37 +0100, [email protected] wrote:
> In case your newly added parseError defense is a bit too strict, i.e.,
> required only to prevent calling malAtomProperty() with curInstr->fcn ==
> NULL, the following patch might be considered:
is possible :)
> diff -r a4f844538f0c monetdb5/mal/mal_parser.mx
> --- a/monetdb5/mal/mal_parser.mx Sun Mar 06 12:59:51 2011 +0100
> +++ b/monetdb5/mal/mal_parser.mx Sun Mar 06 14:01:48 2011 +0100
> @@ -1330,11 +1330,12 @@
> setModuleScope(curInstr,
> findModule(cntxt->nspace,
> putName(modnme,strlen(modnme))) );
> curInstr->fcn = getAddress(cntxt->srcFile, modnme, nme,TRUE);
> - if (curInstr->fcn == NULL)
> - return (MalBlkPtr) parseError(cntxt, "<address> not
> found\n");
> curBlk->binding = nme;
> - if( cntxt->nspace->isAtomModule)
> + if( cntxt->nspace->isAtomModule) {
> + if (curInstr->fcn == NULL)
> + return (MalBlkPtr) xparseError(cntxt,
> "<address> not found\n");
> malAtomProperty(curBlk, curInstr);
> + }
> skipSpace(cntxt);
> } else {
> return (MalBlkPtr) parseError(cntxt,"'address' expected\n");
> ========
>
> This would assume, though, that curInstr->fcn == NULL in other cases is
> properly checked and handled elsewhere ...
Patch looks good to me. If it seems reasonable that you can define
addresses that point to nowhere, then this is ok. I couldn't come up
with any reason why that would be ok when I made this change.
_______________________________________________
Checkin-list mailing list
[email protected]
http://mail.monetdb.org/mailman/listinfo/checkin-list
