Re: [MP3 ENCODER] Please stop breaking LAME... ;)
Mark Taylor wrote: Hi Everyone, I haven't been keeping up with things for the last week, because my wife and I just had our first baby :-) (baby's requisite website: www.wildpuppy.com/baby) Hey! Congrats, Mark! Give my regards to the new mother too. How are they doing? I only wish I knew more about the lil one cos your website seems to be currently down, along with www.sulaco.org But anyway take care and all the best : ) Regards Jason -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Please stop breaking LAME... ;)
C can't cast from type A to type B. There is only the possibility to cast every shit to type B. And this is dangerous. So you write a int ifreq; double dfreq; ifreq = (int) ( dfreq ); and now dfreq changes the type to 'struct bla*'. C converts this without batting an eyelid. ...but doing anything different from address arithmetic won't compile. So if you do anything useful with dfreq, the compiler will catch the error; if you don't do anything useful with it, then a) you don't do _anything_ with it, so no worries, mate or b) it is only part of an API interface, so it's types should be well defined and documented. The example of the X11 problem you give, is typical of X11, and not so much of C typecasts, IMHO. The example X11 implementation is full of evil ineteger - pointer conversions. Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Please stop breaking LAME... ;)
On Mon, 4 Sep 2000, Frank Klemm wrote: :: :: I run gcc 2.95.(3) and SAS/C (the latter is usually much more helpful on :: :: warnings, and still much more forgiving on "errors")... :: Can you add g++ for testing? :: Or also some other C++ compiler? G++ 2.95.2 has the -fpermissive switch that makes most of these errors turn into simple warnings. mailto:[EMAIL PROTECTED] -= Alberto García =- http://www.cryogen.com/berto Clave pública PGP disponible Fidonet: 2:348/105.108 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Please stop breaking LAME... ;)
:: Hi Everyone, :: :: I haven't been keeping up with things for the last week, because :: my wife and I just had our first baby :-) (baby's requisite website: :: www.wildpuppy.com/baby) :: :: Anyway, now LAME CVS fails all my test cases. This is normal since :: small changes in just the order of operations will show up in these :: tests. I normally then track down exactly what is responsible and :: make sure I understand what is going on. But in this case it looks like :: this will not be possible: There are massive differences in every :: single file. Most of them may be long overdue, but for the most part :: they are related to coding style and/or cosmetic. :: what CODING style? Sorry, it is very laborious to only read (not understand) the source code. Currently the first action in the editor is the auto-format features of xjed. It only takes 1 or 2 seconds, but the code can't be checked in anymore. Transmitting the changes from the local copy to the 'commit'-able version is sinewy, especially line by line. It begins with the simpliest things like tabulators '\t' with different sizes (3, 4 and 8 are used in lame), continues with circle references in header files (try to change the type of internal_flags from 'void*' to 'lame_internal_flags*') and ends with dangerous variable names like gfc-stereo and incorrect code due to provoked misunderstandings. It uses some features still tolerated by the ANSI C3.159-1989 standard and strictly forbidden in C99 and C++. A lot of things I've not seen for 3 or 4 years. May be features should be stopped for 2 or 3 days and only these things should be solved. The simpliest way to get a coding style is to use /usr/src/linux/Documentation/CodingStyle . May be there are better coding styles (note that coding styles are also a question of personal taste), but this coding style is the coding style of one of the most successful projects and it is much better than every tohuwabohu. :: It is not approrpriate for new developers to make so many changes so :: quickly without consulting the rest of us. :: Waiting for more than 2 or 3 days makes it nearly impossible to check in changes. That are the results of the usage of SourceSafe at work. -- Mit freundlichen Grüßen Frank Klemm eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED] phone | +49 (3641) 64-2721home: +49 (3641) 390545 sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Please stop breaking LAME... ;)
From: Frank Klemm [mailto:[EMAIL PROTECTED]] Good C Code should be compilable with (nearly) all C(89/95/99) Agreed. (Although there is some perfectly good C89/95 code that is broken by changes in C99 - see endless arguments in news:comp.std.c) and C++ compilers. Good C code compilable as C++ tends to be *bad* C++ code, so why bother? Let the two languages concentrate on what they're good at... But if you're intent on compiling C with a C++ compiler, an automated translator is probably the best approach: you don't need to break/weaken/obfuscate your C code that way. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Please stop breaking LAME... ;)
:: :: Currently my aim is, that the program is compilable with: :: gcc 2.95.2 :: g++ 2.95.2 :: :: I run gcc 2.95.(3) and SAS/C (the latter is usually much more helpful on :: warnings, and still much more forgiving on "errors")... :: Can you add g++ for testing? Or also some other C++ compiler? Or use gcc at monday/wednesday and friday and g++ at the rest? :: :: Also it would be nice if you cast types that don't match the functions :: :: types into the correct one :: Casting is a bad thing. Correct the reason for the casting, not the warning :: (or the error in C++) itself. See Ada Rationale. It is Ada related, but the :: reasons are the same for every procedural language like C, Pascal, Ada, ... :: :: Ofcos, as I said, the best thing is to use the correct one to begin with, but :: if that isn't possible, atleast cast the value into the correct one. :: Write a (inline) function to convert from type A to type B. Wild type casting in C is one of the most dangerous things. C can't cast from type A to type B. There is only the possibility to cast every shit to type B. And this is dangerous. So you write a int ifreq; double dfreq; ifreq = (int) ( dfreq ); and now dfreq changes the type to 'struct bla*'. C converts this without batting an eyelid. Who has corrected the SigSeg fault which occured only with gcc 2.95, but not with g++ 2.95? fread() faulted with unobtrusively parameters in get_audio.c. -- Mit freundlichen Grüßen Frank Klemm eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED] phone | +49 (3641) 64-2721home: +49 (3641) 390545 sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Please stop breaking LAME... ;)
I hope you guys correct all the errors. Please make sure that no new bugs show up on the next beta release! If it's very much "broken" I think it'll be best to start again with a previous alpha, one before someone broke it. Thank you all who are working hard on making LAME such a great encoder! - Zia "Sigbjørn Skjæret" wrote: :: Please check that your code compiles and works ok before checking it in :: to the CVS ... :: That doesn't help fully to solve the problem. Compiler and runtime libs are different. So the check can only be done for one (or two) compilers. Still, it's not fun when certain files fail to compile because of silly errors (like conflicting prototypes). ;) Currently my aim is, that the program is compilable with: gcc 2.95.2 g++ 2.95.2 I run gcc 2.95.(3) and SAS/C (the latter is usually much more helpful on warnings, and still much more forgiving on "errors")... :: Also it would be nice if you cast types that don't match the functions :: types into the correct one Casting is a bad thing. Correct the reason for the casting, not the warning (or the error in C++) itself. See Ada Rationale. It is Ada related, but the reasons are the same for every procedural language like C, Pascal, Ada, ... Ofcos, as I said, the best thing is to use the correct one to begin with, but if that isn't possible, atleast cast the value into the correct one. - CISC -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Please stop breaking LAME... ;)
:: I run gcc 2.95.(3) and SAS/C (the latter is usually much more helpful on :: warnings, and still much more forgiving on "errors")... Can you add g++ for testing? Or also some other C++ compiler? Or use gcc at monday/wednesday and friday and g++ at the rest? I have no incentive to use C++ at all, infact I'm not even interested... :: Ofcos, as I said, the best thing is to use the correct one to begin with, :: but if that isn't possible, atleast cast the value into the correct one. Write a (inline) function to convert from type A to type B. Wild type casting in C is one of the most dangerous things. I'm not talking about "wild" typecasting, I'm saying that strict, controlled typecasting can be good, instead of leaving it up to the compiler to make the choices (which might not always be the correct one)... C can't cast from type A to type B. There is only the possibility to cast every shit to type B. And this is dangerous. So you write a int ifreq; double dfreq; ifreq = (int) ( dfreq ); and now dfreq changes the type to 'struct bla*'. C converts this without batting an eyelid. What the hell are you on about?! Oh, w8, you mean if some smartass changes dfreq to a struct without checking the code, or atleast changing the name so these kinds of conflicts can occur? I'd say he'd be downright stupid. ;) - CISC -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Please stop breaking LAME... ;)
I hope you guys correct all the errors. Please make sure that no new bugs show up on the next beta release! If it's very much "broken" I think it'll be best to start again with a previous alpha, one before someone broke it. Thank you all who are working hard on making LAME such a great encoder! Well, when I checked in the last fixes this morning, everything compiled and ran fine (finally), now there are more changes again, so we'll have to wait and see... ;) - CISC -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Please stop breaking LAME... ;)
Are you sure about that? The Layer2 decoding code doesn't compile for me, and when I try to decode it says something about bug!!?? or something like that, every file I try to decode does it (mp3, I disabled layer1 and layer2 for now just so it would compile). Josh "Sigbjørn Skjæret" wrote: I hope you guys correct all the errors. Please make sure that no new bugs show up on the next beta release! If it's very much "broken" I think it'll be best to start again with a previous alpha, one before someone broke it. Thank you all who are working hard on making LAME such a great encoder! Well, when I checked in the last fixes this morning, everything compiled and ran fine (finally), now there are more changes again, so we'll have to wait and see... ;) - CISC -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Please stop breaking LAME... ;)
Hi Everyone, I haven't been keeping up with things for the last week, because my wife and I just had our first baby :-) (baby's requisite website: www.wildpuppy.com/baby) Anyway, now LAME CVS fails all my test cases. This is normal since small changes in just the order of operations will show up in these tests. I normally then track down exactly what is responsible and make sure I understand what is going on. But in this case it looks like this will not be possible: There are massive differences in every single file. Most of them may be long overdue, but for the most part they are related to coding style and/or cosmetic. It is not approrpriate for new developers to make so many changes so quickly without consulting the rest of us. Later today I will move the latest CVS version into a branch, and revert the main branch back to 'cvs update -D "Aug 31 2000 12:00"' Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Please stop breaking LAME... ;)
Are you sure about that? The Layer2 decoding code doesn't compile for me, and when I try to decode it says something about bug!!?? or something like that, every file I try to decode does it (mp3, I disabled layer1 and layer2 for now just so it would compile). Ah, yes, I hadn't come that far yet (I usually use my own amiga_mpega.c interface)... :P - CISC -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Please stop breaking LAME... ;)
:: :: I run gcc 2.95.(3) and SAS/C (the latter is usually much more helpful on :: :: warnings, and still much more forgiving on "errors")... :: Can you add g++ for testing? :: Or also some other C++ compiler? :: Or use gcc at monday/wednesday and friday and g++ at the rest? :: :: I have no incentive to use C++ at all, infact I'm not even interested... :: You should not use C++, but the C code should not use special C expressions allowed in C89 (ANSI C Standard from 1989), but strictly forbidden in ANSI C++. A lot of them are forbidden in C99 (ANSI C Standard from October 1999). You can't compiler LAME with a C99 compiler. Good C Code should be compilable with (nearly) all C(89/95/99) and C++ compilers. :: I'm not talking about "wild" typecasting, I'm saying that strict, controlled :: typecasting can be good, instead of leaving it up to the compiler to make the :: choices (which might not always be the correct one)... :: :: C can't cast from type A to type B. There is only the possibility to :: cast every shit to type B. And this is dangerous. :: So you write a ::int ifreq; ::double dfreq; ::ifreq = (int) ( dfreq ); :: and now dfreq changes the type to 'struct bla*'. :: C converts this without batting an eyelid. :: :: What the hell are you on about?! :: :: Oh, w8, you mean if some smartass changes dfreq to a struct without checking :: the code, or atleast changing the name so these kinds of conflicts can occur? :: :: I'd say he'd be downright stupid. ;) :: Some of these bugs are parts of international standards. The most well known is one in the Unix X11 system. It was found 15 years after it was programmed while porting X11 for Ada. Noone need to be a smartass to make such errors. If you write a C program with 1 serious error/1500 LOC, you are a top programmer. -- Mit freundlichen Grüßen Frank Klemm eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED] phone | +49 (3641) 64-2721home: +49 (3641) 390545 sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Please stop breaking LAME... ;)
:: Please check that your code compiles and works ok before checking it in to
:: the CVS ...
::
That doesn't help fully to solve the problem. Compiler and runtime libs are
different. So the check can only be done for one (or two) compilers.
Another problem are interferencing code changes in the evaluation phase
(currently 1 hour at my computer).
Currently my aim is, that the program is compilable with:
gcc 2.95.2
g++ 2.95.2
It is generally a good idea if a C program is (also) compilable with a C++
compiler. I've patched a lot of code, reached the aim at 5:30 a.m.
and now I got an executable. Several hundreds of warnings are remaining.
layer1 and layer2 decoding I have disabled. There are some ugly things in
it, I must correct separately:
struct bla {
int i;
char c;
};
typedef struct bla bla [32] [64];
struct bla a1;
bla a2;
a1 [12] [7] . c = 12;
a2 . c = 7;
Really nasty hacking stuff. C++ forbits it strictly.
In the future I suggest to test the code with C *and* C++.
It also increases the chance of portable ANSI C code.
:: I've repeatedly had to go fix compile errors in the CVS now... :P
::
I too.
:: Also it would be nice if you cast types that don't match the functions types
:: into the correct one
::
Casting is a bad thing. Correct the reason for the casting, not the warning
(or the error in C++) itself. See Ada Rationale. It is Ada related, but the
reasons are the same for every procedural language like C, Pascal, Ada, ...
Another idea is to use separate types for separate items. Changing the type
of an item becomes easy. The idea of C is that everything is an int, but
that isn't a very nice idea. You mix too much things with are fully
incompatible. And a sample frequency is for one person a long, for the next
a int, for a 3rd a unsigned int, the 4rd takes a float to save storage
and the last one takes a long double to reduce the danger of roundings.
Casts are the wrong way to hide this mess.
typedef long double samplefreq_t;
samplefreq_t in_sample_freq = 44100;
No mixtures of int, long, unsigned, float and double.
:: (or use the correct one to begin with) .. it's both the
:: correct and nice way to do it...
::
:: Also don't set ambigous types like "unsigned", use the proper full name,
:: "unsigned int".
::
Right. Some of them I have fixed, some of them are mine ;-(
:: And a problem I can't figure out right now is why LAME won't encode at all
:: anymore, it just creates an empty mp3 (that means it atleast opens it), and
:: then quits saying "Error writing mp3, disk full?" .. what have you done? ;)
::
Fixed. Bug of mime.
I've added a check of the return value of the final fwrite().
There are runtime libs out there which reports an error for the request of
writing 1 item of 0 bytes.
--
Mit freundlichen Grüßen
Frank Klemm
eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED]
phone | +49 (3641) 64-2721home: +49 (3641) 390545
sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Please stop breaking LAME... ;)
:: Please check that your code compiles and works ok before checking it in :: to the CVS ... :: That doesn't help fully to solve the problem. Compiler and runtime libs are different. So the check can only be done for one (or two) compilers. Still, it's not fun when certain files fail to compile because of silly errors (like conflicting prototypes). ;) Currently my aim is, that the program is compilable with: gcc 2.95.2 g++ 2.95.2 I run gcc 2.95.(3) and SAS/C (the latter is usually much more helpful on warnings, and still much more forgiving on "errors")... :: Also it would be nice if you cast types that don't match the functions :: types into the correct one Casting is a bad thing. Correct the reason for the casting, not the warning (or the error in C++) itself. See Ada Rationale. It is Ada related, but the reasons are the same for every procedural language like C, Pascal, Ada, ... Ofcos, as I said, the best thing is to use the correct one to begin with, but if that isn't possible, atleast cast the value into the correct one. - CISC -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
