public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Dodji Seketeli <dodji@redhat.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: "GCC Patches" <gcc-patches@gcc.gnu.org>,
	"Tom Tromey" <tromey@redhat.com>,
	"Manuel López-Ibáñez" <lopezibanez@gmail.com>,
	"Bernd Edlinger" <bernd.edlinger@hotmail.de>
Subject: Re: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals
Date: Mon, 11 Nov 2013 17:13:00 -0000	[thread overview]
Message-ID: <878uwuap4f.fsf@redhat.com> (raw)
In-Reply-To: <20131111142159.GZ27813@tucnak.zalov.cz> (Jakub Jelinek's message	of "Mon, 11 Nov 2013 15:21:59 +0100")

Jakub Jelinek <jakub@redhat.com> writes:

>> -OBJS-libcommon = diagnostic.o diagnostic-color.o pretty-print.o intl.o input.o version.o
>> +OBJS-libcommon = diagnostic.o diagnostic-color.o pretty-print.o intl.o vec.o input.o version.o
>
> Too long line?

Fixed in my local copy of the patch, thanks.

>
>> +      if (c == '\0')
>> +	c = ' ';
>>        pp_character (context->printer, c);
>
> Does that match how libcpp counts the embedded '\0' character in column
> computation?

Yes, I think so.  _cpp_lex_direct in libcpp/lex.c considers '\0' just
like a white space and so the column number is incremented when it's
encountered.

>> +    /* The position (byte count) the the last byte of the line.  This
>> +       normally points to the '\n' character, or to one byte after the
>> +       last byte of the file, if the file doesn't contain a '\n'
>> +       character.  */
>> +    size_t end_pos;
>
> Does it really help to note this?  You can always just walk the line from
> start_pos looking for '\n' or end of file.

Yes you are right, it's not strictly necessary.  But with that end_pos,
copying a line is even faster; no need of walking.  I thought the goal
was to avoid re-doing the work we've already done, as much as possible.

>
>> +static fcache*
>> +add_file_to_cache_tab (const char *file_path)
>> +{
>> +  static size_t idx;
>> +  fcache *r;
>> +
>> +  FILE *fp = fopen (file_path, "r");
>> +  if (ferror (fp))
>> +    {
>> +      fclose (fp);
>> +      return NULL;
>> +    }
>> +
>> +  r = &fcache_tab[idx];
>
> Wouldn't it be better to use some LRU algorithm to determine which
> file to kick out of the cache?  Have some tick counter of cache lookups (or
> creation) and assign the tick counter to the just created resp. used
> cache entry, and remove the one with the smallest counter?

Hehe, the LRU idea occurred to me too, but I dismissed the idea as
something probably over-engineered.  But now that you are mentioning it
I guess I should give it a try ;-) I'll post a patch about that later
then.

>> +  fcache * r = lookup_file_in_cache_tab (file_path);
>> +  if (r ==  NULL)
>
> Formatting (no space after *, extra space after ==).

Fixed in my local copy.  Thanks.

-- 
		Dodji

  reply	other threads:[~2013-11-11 16:18 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-31 14:48 Bernd Edlinger
2013-10-31 15:06 ` Jakub Jelinek
2013-10-31 15:19   ` Dodji Seketeli
2013-10-31 18:26     ` Jakub Jelinek
2013-11-04 11:52       ` Dodji Seketeli
2013-11-04 11:59         ` Jakub Jelinek
2013-11-04 15:42           ` Dodji Seketeli
2013-11-05  0:10             ` Bernd Edlinger
2013-11-05  9:50               ` Dodji Seketeli
2013-11-05 11:19                 ` Bernd Edlinger
2013-11-05 11:43                   ` Dodji Seketeli
2013-11-06 22:27                 ` Bernd Edlinger
2013-11-04 12:06         ` Bernd Edlinger
2013-11-04 12:15           ` Jakub Jelinek
2013-11-04 12:32             ` Bernd Edlinger
2013-11-04 15:21           ` Dodji Seketeli
2013-11-11 10:49       ` Dodji Seketeli
2013-11-11 14:35         ` Jakub Jelinek
2013-11-11 17:13           ` Dodji Seketeli [this message]
2013-11-12 16:42             ` Dodji Seketeli
2013-11-13  5:10               ` Bernd Edlinger
2013-11-13  9:40                 ` Dodji Seketeli
2013-11-13  9:43                   ` Bernd Edlinger
2013-11-13  9:49                     ` Dodji Seketeli
2013-11-13  9:49                     ` Dodji Seketeli
2013-11-13  9:51               ` Jakub Jelinek
2013-11-14 15:12                 ` Dodji Seketeli
2013-12-09 20:11                   ` Tom Tromey
2014-01-21 12:28                   ` Bernd Edlinger
2014-01-22  8:16                     ` Dodji Seketeli
2014-01-23 17:12                       ` Jakub Jelinek
2014-01-24  2:58                         ` Bernd Edlinger
2014-01-24  7:53                         ` Dodji Seketeli
2014-01-24 15:05                       ` Markus Trippelsdorf
2014-01-24 15:41                         ` Dodji Seketeli
2014-01-24 15:44                           ` Jakub Jelinek
2014-01-24 16:09                             ` Dodji Seketeli
2014-01-24 16:13                               ` Jakub Jelinek
2014-01-24 23:02                               ` Markus Trippelsdorf
2014-01-24 23:20                                 ` Markus Trippelsdorf
2014-01-28 13:20                                   ` Dodji Seketeli
2014-01-28 13:23                                     ` Dodji Seketeli
2014-01-28 18:40                                       ` H.J. Lu
2014-01-29 11:28                                         ` Dodji Seketeli
  -- strict thread matches above, loose matches on Subject: below --
2013-10-31 13:45 Dodji Seketeli
2013-10-31 17:30 ` Manuel López-Ibáñez

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=878uwuap4f.fsf@redhat.com \
    --to=dodji@redhat.com \
    --cc=bernd.edlinger@hotmail.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=lopezibanez@gmail.com \
    --cc=tromey@redhat.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).