Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Pierre Muller <muller@ics.u-strasbg.fr>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA] Add handling of null Ada arrays
Date: Wed, 09 Jan 2008 17:17:00 -0000	[thread overview]
Message-ID: <20080109171715.GD21281@adacore.com> (raw)
In-Reply-To: <000401c852a1$0bdb1aa0$23914fe0$@u-strasbg.fr>

>   At least in pascal language it is quite
> common to use things like 
> type
>   BigArray = Array [1..0xffffffff] of integer;
> if you want to be sure that you will never get into 
> troubles due to range checking...

That's ... strange :).

>   Of course you cannot allocate a pointer to such a type
> directly, and it would eat up a lot of memory space.

Right. If you did that in Ada, you would immediately trigger
an exception. In fact, I believe that GNAT detects static cases
like this and replaces the code with an exception raise.

How does the above work in Pascal? If the program hasn't "allocated
a pointer to such type", does it mean that the size of the array is
dynamic and grown as needed? I think it's be interesting to understand
how it works underneath if we want to improve the situation for Pascal
too.

On my end, my Pascal days are long behind me (I think the last time
I wrote some Pascal was in 92 or 93), but I thought that Pascal arrays
were allocated when declared and that the bounds could not be changed
after...

> But this kind of types always gave problems inside gdb, because when
> you wanted to look at the value gdb would try to copy the whole
> array...  even if cases where it would only display the first
> elements, which is kind of silly, no?

We had the exact same issue with Ada, actually. Paul Hilfinger
fixed it for us.

The good news is that my patch should avoid GDB trying to allocate
0xffffffff bytes for your array, which usually leads to a debugger
crash ;-).

-- 
Joel


  reply	other threads:[~2008-01-09 17:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-09  6:34 Joel Brobecker
2008-01-09  9:22 ` Pierre Muller
2008-01-09 17:17   ` Joel Brobecker [this message]
2008-01-09 19:05   ` Jim Blandy
2008-01-09 12:47 ` Daniel Jacobowitz
2008-01-09 17:07   ` Joel Brobecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080109171715.GD21281@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=muller@ics.u-strasbg.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox