Re: Enlarge MAX_ALLOCA?

[handa@gnu.org (K. Handa)]

In article <83egyitlbq.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > And, yes, we can estimate the actually necessarey
> > CHARBUF_SIZE as coding->src_bytes on decoding, and
> > coding->src_chars on encoding.

> Does the patch below look OK to you?  I tried it, but it seems to
> cause trouble when byte-compiling: Emacs enters some kind of infloop.
> Perhaps I misunderstood what you meant?

I have not yet tested your patch, but I think it is better
to limit the maximum allocation size to the current
CHARBUF_SIZE, and also limit the mininum allocation size to
16 units or so.  The latter is because some of
encode_coding_XXXX need at least a few more slots left in
coding->charbuf.

> > By the way, perhaps the most effective way for making
> > ENCODE_FILE faster and less memory-touching is to change
> > encode_file_name return FNAME when FNAME contains ASCII
> > only or file-name-coding-system is utf-8.

> This would be a good improvement, as most platforms we care about use
> UTF-8 for file-name encoding these days.  Could you please suggest
> such changes?

Ok, I'll work on it.

---
Kenichi Handa
handa@gnu.org