This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfc][13/37] Eliminate builtin_type_ macros: Update EVAL_SKIP dummy return type


> >     nosideret:
> >       return value_from_longest (builtin_type_long, (LONGEST) 1);
> > 
> > If we have a value_dummy() function, we can replace all gotos with
> > a "return value_dummy ()", and get rid of the label. I think it will 
> > be more readable.
> 
> I tried to have evaluate_subexp return NULL for the EVAL_SKIP case,
> but that caused frequently-used constructe like this to break:
> 
>       arg1 = evaluate_subexp (NULL_TYPE, exp, pos, noside);
>       arg2 = evaluate_subexp (value_type (arg1), exp, pos, noside);
> 
>       if (noside == EVAL_SKIP || noside == EVAL_AVOID_SIDE_EFFECTS)
>         return arg1;

Right, I think the expectation for evaluate_subexp was that it would
never return NULL - either it errors out or returns a valid value.

What I meant in my message above is that we could have a new procedure
that returns a valid value of some kind, but whose content is
unspecified - to be used in cases like EVAL_SKIP when we don't really
care about. The function is there more as a shortcut for building
that dummy value. Your suggestion of using allocate_value (builtin_void_type)
might actually be even better than using builtin_type_int8 - we should
never read the value contents anyway.

> I guess with a bit of effort those could be fixed.

Not worth it, IMO.

-- 
Joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]