Hello, Mark.
on 99.11.9 10:29 AM, Mark Taylor at [EMAIL PROTECTED] wrote:
> I've got so many patches which change all the c++ comments to c style,
> I finally gave in and got rid of all the //'s :-)
Thank you very much for your job!
>>> 2. To solve the problem of local data >32k in file "lame.c", I moved the
>>> large arrays outside the local function. In other words, I made them
>>> global within the file.
>
> What kind of compiler would have a 32k limit for data on the stack???
> The Amiga seemed to have this problem, but you could set some option
> to increase the limit.
I don't know why this limit exists on PowerPC machines, though, both
Metroworks CodeWarrior and MPW (Free C/C++ Development environment by Apple)
have this limit. Known by reports on other Japanese mailing list, MPW has
critial bug obtaining large stack more than 32K. (We can compile, but it
will not work.) I don't use MPW so I don't know this is truth or not.
To solve this problem, I put "static" before large array. This is not
important, serious for me. But the codes of LAME have so may globals,
statics, and this makes hard to understanding the flow of prosess to me.
Hope to be changed to use struct (pointers).
And one more suggestion. Macintosh programmers could not use f_open()
function because Macintosh has no full path consept. Windows, or UNIX has a
path, but Macintosh has not. Hard drive name is not specified and it can be
easy changed. Of course, file name may be contain spaces.
So don't use file name to specify the file. Hope to use FILE* to specify the
input/output file. With this change, I will be able to port LAME easiler.
ie.
typedef struct input_t
{
char* file; /* file name */
FILE* fp; /* file pointer */
/* and so on... */
} input_t;
typedef struct confing_t
{
input_t* input;
output_t* output;
VBR_t* VBR;
ID3_t* ID3;
/* and so on... */
} config_t;
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
