Issue 26345 - macro size limits ..
Summary: macro size limits ..
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: OOo 1.1.1RC
Hardware: All All
: P2 Trivial with 1 vote (vote)
Target Milestone: ---
Assignee: ab
QA Contact: issues@framework
Keywords: oooqa
Depends on:
Reported: 2004-03-11 15:17 UTC by mmeeks
Modified: 2004-08-04 09:34 UTC (History)
4 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---

large file support (11.88 KB, patch)
2004-03-11 15:17 UTC, mmeeks
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description mmeeks 2004-03-11 15:17:12 UTC
It being extremely unclear to me where to file this, and IZ's bug filing page
being almost useless from a hackers' perspective; I thought I'd file it here -
apologies for the noise.

This resurrects a fix from cws_srx645_ab05vba - removing a length limitation in
StarBasic, and reflecting that in the import code; it's a pre-amble for my MS
macro export work :-)
Comment 1 mmeeks 2004-03-11 15:17:50 UTC
Created attachment 13719 [details]
large file support
Comment 2 andrew 2004-03-16 20:11:32 UTC
I recently saw the follwoing post that might be the same problem...

Is there a size limitation for OpenOffice macro modules (I'm using 1.1.0 and
1.1.1rc and it's the same in both)?

I have a macro and everything is fine. I add a few comments, and everything
stops working, and when I do a Tools->Macro->Macros..., my module has *no
functions/subroutines", but if I delete one character from the end of a comment,
then I get to see them all again... If I keep adding comments, then I get bogus
syntax errors that seem to wander over my code when I compile. Reduce the amount
of text in the file and it works again...

Has anyone else seen this, or is this a known "limitation'?

The comments thing happens when I go from 72364 to 72365 characters.

Is this some kind of *buffer overrun* problem? Augh if it is!
Comment 3 jbotte 2004-03-18 15:18:13 UTC
I was the one who posted the question repeated below by pitonyak. Since then,
"DannyB", the moderator of the " Macros and API" forum on, posted the following:

There is definitely an upper limit to the size of a macro.

I'm not sure what the limit is. I think it may be a limit on the size of the
source text. But it might be a limit on the compiled bytecode.

I have a tool that takes an arbitrary binary file and encodes it into a Basic
function that can reconstruct the file. When the Basic function exceeds a
certian size, my encoder tool must break it into multiple numbered functions,
each in a different module. What I'm saying is that I have definitely
encountered a hard upper limit on the size of a module.

This sounds like a real bug to me, and I replied with:

this seems to me like a fairly serious bug... Not only is it undocumented
behaviour, but the symptoms of this bug are not consistent, implying that
something is out of control... never a good thing with software. In fact, it
sounds like a buffer overrun condition exists and that scares the heck out of me
(can you say worm?)!

It sounds to me like you've implemented a workaround to this bug, but it's still
a bug. It's obviously not going to be fixed in 1.1.1, but it's something that
should probably be addressed in the 2.0 timeframe.

The thing that concerns me more than anything is the failure mode seems
progressive: as the file gets longer and longer, more things start to break. If
there is a limit, it really should be a truly hard limit that is checked against
as the file is being loaded in.

Also if the limit is supposed to be 64K (my files started to break at about
72K), this is too small for non-trivial applications.
Comment 4 jbotte 2004-03-18 16:12:39 UTC
Could someone please change this to "Component: framework" and "Priority: P2"? I
don't have the permissions to do that.
Comment 5 flibby05 2004-03-19 12:50:23 UTC
>> Could someone please change this to "Component: framework" and "Priority: P2"? 
>> I don't have the permissions to do that.

read issue, ok for me, done.
Comment 6 jbotte 2004-03-19 15:44:52 UTC
Thank you *very* much for changing that!

Question: Shouldn't it be "Subcomponent: code" as well?
Comment 7 flibby05 2004-03-20 15:00:49 UTC
I don't think so, because this issue does not provide a "reference [to] a piece
of source code" in the OpenOffice.Org Source.

Comment 8 jbotte 2004-03-22 13:49:42 UTC
Ah... I had not run across that before. Thanks, and agreed.
Comment 9 flibby05 2004-03-22 13:55:30 UTC
you can reach it, if you click on "Subcomponent", which itself is a weblink.
Comment 10 stx123 2004-05-11 12:42:21 UTC
Caolan uses the login 'cmc' (cc'ed).
I'm reassigning to the default owner.
Comment 11 caolanm 2004-05-11 15:01:09 UTC
Thats the fix from cws_srx645_ab05vba, but if I recall correctly the VBA
importer used to split the macros because originally StarBasic couldn't handle
larger than 16bit len strings as it used UniString, now it uses OUString. 

So the patch is good to go, but cws_srx645_ab05vba will be merged eventually to
2.0 to fix it there as well as other good stuff from that workspace. I don't
know if cws_srx645_ab05vba is already slated to go into a 1.1.X series though ?
If not this is a good thing to backport (assuming that StarBasic really does use
OUString already in the 1.1.X series)
Comment 12 mci 2004-05-12 10:15:03 UTC
reassigned to jsk

@jsk: Hi, I think this is something for you....
Comment 13 Martin Hollmichel 2004-05-18 11:38:51 UTC
what target milestone we are speaking about ?
Comment 14 joerg.skottke 2004-06-16 10:08:32 UTC
jsk->ab: what do you think?
Comment 15 ab 2004-06-16 10:33:22 UTC
There are already StarOffice internal tasks for this. 
I keep this one anyway to track the subject  for OOo...
Comment 16 ab 2004-08-04 09:32:51 UTC
WONTFIX only refers to the patch changing the import of big modules.
The patch in Basic is covered by a different Star Office internal task.
Comment 17 ab 2004-08-04 09:34:17 UTC
CLOSED, agreed by mmeeks