This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Remove hardcoded limit on max error message length
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Tobias Schlueter <tobias dot schlueter at physik dot uni-muenchen dot de>
- Cc: gcc-patches at gcc dot gnu dot org, fortran at gcc dot gnu dot org
- Date: Thu, 14 Jul 2005 03:29:10 -0400
- Subject: Re: [PATCH] Remove hardcoded limit on max error message length
- References: <20050712091201.GR4884@devserv.devel.redhat.com> <42D584C8.8000407@physik.uni-muenchen.de>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Jul 13, 2005 at 11:16:56PM +0200, Tobias Schl?ter wrote:
> I'm wondering if making error_buffer and warning_buffer pointers, and changing
> gfc_error_buf to
> typedef struct gfc_error_buf
> {
> int flag;
> char message[MAX_ERROR_MESSAGE];
> size_t allocated;
> size_t index; /* instead of cur_ptr, index into the message array */
> char message[];
> } gfc_error_buf;
> and then doing away with the pointer arithmetic would be simpler.
>From the above I'm not 100% sure what exactly you are suggesting.
Is that:
1) making the message be a flexible array member of the structure?
That doesn't sound to be an advantage, as gfc_{push,pop,free}_error
would need to use something else, and we'd have to allocate the
structure separately first
2) putting a message buffer with fixed limit into the structure
and just use some malloced buffer instead when we go over that
initial limit?
3) just using an index into the array instead of pointer
(i.e. replacing cur_ptr with index)?
3) would simplify the code, 2) would complicate it, but avoid some
malloc/free calls, 1) I don't see as an advantage.
> Otherwise this is ok. How did you find the place where you inserted
> gfc_free_error? Is that list exhaustive?
Yes, it is exhaustive. I have grepped for all occurences of
gfc_(push|pop)_error and checked them all.
Jakub