This is the mail archive of the 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] Strings and arrays without malloc

> Here's some things which call malloc today, and do not with the patch
> applied - yes, even the sizeof and ptype ones:

Woohoo! :)

> Here's some expressions which used to call malloc and still do; these
> are operations which involve pointers, so we need to call malloc to
> get a valid pointer for them.
>   print *"abc"
>   print "abc" + 1
>   print &"abc"
>   print strcmp ("abc", "def")
>   print &{4, 5, 6}

Honestly, except maybe for the case where strcmp is involved, I find
that the semantics of the expressions could be debated. But you were
able to preserve the previous behavior, which is great.

> Here's some expressions which used to call malloc and will now produce
> an error about "value not located in memory":
>   print &{4, 5, 6}[1]
>   ptype &{4, 5, 6}[1]

As per the above, I personally am not really all that much concerned
about this kind of limitation, and I agree that subscripting is more
interesting than getting the address of a subscripted element.

It's still possible to get the answer by doing a sequence of
commands instead of one convenient expression, but the following
should work, right?

    print &{4, 5, 6}
    print &(*$)[1]

Or, in one expression (if I get my precedence right):

    print &(*&{4, 5, 6})[1]

Perhaps we could add this to the documentation too.

I haven't looked at the code itself, but the benefits are really
exciting IMO.


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