Menu
▾
▴
sc2-devel — For developers
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(90) |
Sep
(74) |
Oct
(56) |
Nov
(13) |
Dec
(139) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(22) |
Feb
(6) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
(11) |
Sep
(6) |
Oct
|
Nov
(7) |
Dec
(4) |
| 2004 |
Jan
(2) |
Feb
(3) |
Mar
(5) |
Apr
(1) |
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
| 2006 |
Jan
|
Feb
(5) |
Mar
|
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(7) |
Oct
(1) |
Nov
(2) |
Dec
(6) |
| 2007 |
Jan
(4) |
Feb
(8) |
Mar
|
Apr
|
May
(4) |
Jun
(6) |
Jul
(8) |
Aug
(26) |
Sep
(18) |
Oct
(6) |
Nov
(6) |
Dec
(4) |
| 2008 |
Jan
(6) |
Feb
|
Mar
(2) |
Apr
(2) |
May
(1) |
Jun
(2) |
Jul
(3) |
Aug
|
Sep
(12) |
Oct
(11) |
Nov
(43) |
Dec
(64) |
| 2009 |
Jan
(59) |
Feb
(18) |
Mar
(41) |
Apr
(38) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jim M. <jim...@co...> - 2002-12-15 01:15:41
|
Hello,
It seems my C is a bit rusty, could some one explain how the following
#define is expanded. I understand simple macro's, but can't figure out how
the game states are being loaded.
#define START_GAME_STATE enum
{
#define ADD_GAME_STATE (SName,NumBits) SName, END_##SName = SName +
NumBits - 1,
#define END_GAME_STATE NUM_GAME_STATE_BITS
};
START_GAME_STATE
/* Shofixti states */
ADD_GAME_STATE (SHOFIXTI_VISITS, 3)
...
END_GAME_STATE
Thanks,
Jim
|
|
From: Lee T. <tho...@lo...> - 2002-12-13 23:35:30
|
On Fri, 13 Dec 2002 17:29:52 -0500, you wrote: > > I tested that and it works fine for me.. are you sure your vorbis libs > > aren't outdated for example? Or it might be some more hideous bug in our > > code also. > > > > 19.07.2002 07:34 49 152 ogg.dll > > 19.07.2002 07:34 974 848 vorbis.dll > > 19.07.2002 07:35 28 672 vorbisfile.dll > > > > Those are the ones I use, from oggvorbis win32 sdk. > > Yep, that was exactly the problem. My DLLs were from Nov., 2001. > > Now, it doesn't take forever when loading the .OGG files, and they all work > perfectly. > > Still, it's a good guard to have in the code incase someone screws up their > ogg files. Should probably add a check in the installer to version the DLLs and warn or something if they are old. -- Lee Thompson tho...@lo... |
|
From: Chris G. <ch...@il...> - 2002-12-13 22:29:34
|
> I tested that and it works fine for me.. are you sure your vorbis libs > aren't outdated for example? Or it might be some more hideous bug in our > code also. > > 19.07.2002 07:34 49 152 ogg.dll > 19.07.2002 07:34 974 848 vorbis.dll > 19.07.2002 07:35 28 672 vorbisfile.dll > > Those are the ones I use, from oggvorbis win32 sdk. Yep, that was exactly the problem. My DLLs were from Nov., 2001. Now, it doesn't take forever when loading the .OGG files, and they all work perfectly. Still, it's a good guard to have in the code incase someone screws up their ogg files. |
|
From: Mika K. <mim...@cc...> - 2002-12-13 21:20:28
|
On Fri, 13 Dec 2002, Chris Gahan wrote: > > Ok, the lockup is now fixed in CVS. Could you be more specific about > > which .ogg files fail to play, so I could debug this problem? >=20 > What happens every time I go to the Starbase in a certain game, is that > SpliceTrack() takes a very long time to load starb015.ogg (before the > Starbase commander fades in), then as soon as he's tries to talk, the g= ame > freezes. I tested that and it works fine for me.. are you sure your vorbis libs=20 aren't outdated for example? Or it might be some more hideous bug in our=20 code also. 19.07.2002 07:34 49=A0152 ogg.dll 19.07.2002 07:34 974=A0848 vorbis.dll 19.07.2002 07:35 28=A0672 vorbisfile.dll Those are the ones I use, from oggvorbis win32 sdk. -- Mika Kolehmainen <mim...@cc...> |
|
From: Chris G. <ch...@il...> - 2002-12-13 21:12:14
|
I just noticed this when testing the new bad-ogg patch... If you talk to the Starbase Commander using this saved game, then go to "Need Background Information", then "Would like input on how we can defeat the Ur-Quan", one of your questions is something the captain is supposed to say! " There is something I think you should know" I traced through the code a bit to find which question triggers the captain's response... The question it should be showing this: #(what_do_now) If you were in my shoes, what would you do now? Which appears at the end of starbas.txt. So, if anyone wants to figure out what's wrong, be my guest. :) = Chris Gahan ============= (ch...@il...) |
|
From: Chris G. <ch...@il...> - 2002-12-13 20:56:09
|
> Ok, the lockup is now fixed in CVS. Could you be more specific about > which .ogg files fail to play, so I could debug this problem? What happens every time I go to the Starbase in a certain game, is that SpliceTrack() takes a very long time to load starb015.ogg (before the Starbase commander fades in), then as soon as he's tries to talk, the game freezes. = Chris Gahan ============= (ch...@il...) |
|
From: Mika K. <mim...@cc...> - 2002-12-13 15:34:53
|
On Fri, 13 Dec 2002, Chris Gahan wrote: > I'm not sure why this is, but talking with some people (the Starbase > Commander, the talking pet, the Arilou) will freeze the game every time when > trying to play certain speech files. I found out that it's because the > soundSource[SPEECH_SOURCE].sbuf_size is 0, and it just loops infinitely. > It's weird since the speech file is there, and it plays fine in Winamp. The > problem is with the same speech file every time. Ok, the lockup is now fixed in CVS. Could you be more specific about which .ogg files fail to play, so I could debug this problem? -- Mika Kolehmainen <mim...@cc...> |
|
From: J <Sp...@th...> - 2002-12-13 10:03:39
|
How were the oggs encoded?
Cause there are a great many options you can use when encoding them.
Possibly the lib that UQM uses to play ogg streams doesnt like some settings
?
I remember having those sorts of problems with MP3's when they first came
out, MP3's with odd bitrates/sample rates would cause
corruption/crashes/far-out behaviour in some decoding libraries..
----- Original Message -----
From: "Chris Gahan" <ch...@il...>
To: <sc2...@li...>
Sent: Friday, December 13, 2002 8:21 PM
Subject: [Sc2-devel] [PATCH] Speech that freezes the game...
> I'm not sure why this is, but talking with some people (the Starbase
> Commander, the talking pet, the Arilou) will freeze the game every time
when
> trying to play certain speech files. I found out that it's because the
> soundSource[SPEECH_SOURCE].sbuf_size is 0, and it just loops infinitely.
> It's weird since the speech file is there, and it plays fine in Winamp.
The
> problem is with the same speech file every time.
>
> Here's a quick patch. It adds a guard condition so that if there is
nothing
> in the sbuf, the game won't crash. It doesn't fix the underlying problem
of
> .oggs not playing, but it will make the game survive if some clever user
> screws up their .ogg files somehow. :)
>
> --- SNIP ---
>
> --- trackplayer.c 2002-12-13 02:12:30.000000000 -0500
> +++ trackplayer.c-new 2002-12-13 00:28:08.000000000 -0500
> @@ -304,7 +304,7 @@
>
> for (;;)
> {
> - if (pos >= soundSource[SPEECH_SOURCE].sbuf_size)
> + if (pos >= soundSource[SPEECH_SOURCE].sbuf_size &&
> soundSource[SPEECH_SOURCE].sbuf_size > 0)
> pos = pos - soundSource[SPEECH_SOURCE].sbuf_size;
> else
> break;
>
> --- SNIP ---
>
>
> = Chris Gahan =============
> (ch...@il...)
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Sc2-devel mailing list
> Sc2...@li...
> https://lists.sourceforge.net/lists/listinfo/sc2-devel
>
|
|
From: Chris G. <ch...@il...> - 2002-12-13 07:21:46
|
I'm not sure why this is, but talking with some people (the Starbase
Commander, the talking pet, the Arilou) will freeze the game every time when
trying to play certain speech files. I found out that it's because the
soundSource[SPEECH_SOURCE].sbuf_size is 0, and it just loops infinitely.
It's weird since the speech file is there, and it plays fine in Winamp. The
problem is with the same speech file every time.
Here's a quick patch. It adds a guard condition so that if there is nothing
in the sbuf, the game won't crash. It doesn't fix the underlying problem of
.oggs not playing, but it will make the game survive if some clever user
screws up their .ogg files somehow. :)
--- SNIP ---
--- trackplayer.c 2002-12-13 02:12:30.000000000 -0500
+++ trackplayer.c-new 2002-12-13 00:28:08.000000000 -0500
@@ -304,7 +304,7 @@
for (;;)
{
- if (pos >= soundSource[SPEECH_SOURCE].sbuf_size)
+ if (pos >= soundSource[SPEECH_SOURCE].sbuf_size &&
soundSource[SPEECH_SOURCE].sbuf_size > 0)
pos = pos - soundSource[SPEECH_SOURCE].sbuf_size;
else
break;
--- SNIP ---
= Chris Gahan =============
(ch...@il...)
|
|
From: Tim D. <zi...@ya...> - 2002-12-13 01:48:49
|
I successfully built UGM under MinGW and MSYS (a port of GCC and various GNU utilities to Win32). Attached is instructions for how I did it. It was surprisingly easy, but I may have forgotten something as I wrote this from memory, so let me know if it doesn't work. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Chris N. <ch...@to...> - 2002-12-12 12:06:06
|
Currently, the art and music for UQM is distributed under a license that's less free than we desire. The reason for this is that we wanted to ensure that, once we choose the final license, it won't allow for other companies to incorporate any part of UQM (be it the source code, or the media) into their games, without allowing for these games to be Open and Free (in general terms). TFB is currently reviewing a license which we believe might fit our criteria: The Free Art License. One hypothetical situation I believe it doesn't prevent is the use of an UQM character in an unrelated commercial. Although we'd just as soon not allow this, it seems like quite an improbable scenario. If it actually occured, we'd probably be more amused and preplexed than anything else. We'd also like to hear your opinions on this license, and whether you believe it will allow for sufficient freedom to use the art in fan works, such as clones. Also, if there's a different license which you believe would work better, post a link, and say why you think we should use it instead, and we'll check it out. -- Chris Nelson <ch...@to...> TFB |
|
From: Max W. <wo...@ma...> - 2002-12-11 18:54:01
|
Howdy all! When is the next version going to come out? There were some performance issues in previous installer (windows), it kept taking 100% CPU usage. If needed, I can wrap the next windows version installer. Should we exclude the content from next win32 installer, because half of the people already have it I guess... If not, they can grab the content.tar.gz And what do I need to compile the win32 version?, I have devc++ but somehow I think that I would have to download half of the net to get the needed libs and stuff.. So in next version if someone could compile the new .exe and send it to me and then I could upload the new installer somewhere. - wombat |
|
From: Guillaume R. <de...@ma...> - 2002-12-09 23:35:25
|
[Contrib-RPM] =2D-=3D-=3D-=3D Name : uqm Relocations: (not relocateable) Version : 0.1 Vendor: MandrakeSoft Release : 1mdk Build Date: Mon Dec 9 22:57:31 2002 Install date: (not installed) Build Host: klama.mandrake.org Group : Games/Strategy Source RPM: (none) Size : 538974 License: GPL Packager : Guillaume Rousse <g.r...@li...> URL : http://sc2.sourceforge.net Summary : The Ur-Quan Masters Description : The Ur-Quan Masters is a port of the 3DO version of Star Control 2. =2D-=3D-=3D-=3D * Mon Dec 09 2002 Guillaume Rousse <g.r...@li...> 0.1-1mdk =2D initial mdk package, based on Ville Skytt=E4 <ville.skytta at iki.fi> w= ork =2D-=3D-=3D-=3D =2D-=3D-=3D-=3D =2D-=3D-=3D-=3D =2D- http://www.mandrake-linux.com/en/cookerdevel.php3 |
|
From: Guillaume R. <de...@ma...> - 2002-12-09 23:35:17
|
[Contrib-RPM] =2D-=3D-=3D-=3D Name : uqm-data Relocations: (not relocateable) Version : 0.1 Vendor: MandrakeSoft Release : 1mdk Build Date: Tue Dec 10 00:06:04 2002 Install date: (not installed) Build Host: klama.mandrake.org Group : Games/Strategy Source RPM: (none) Size : 133755189 License: GPL Packager : Guillaume Rousse <g.r...@li...> URL : http://sc2.sourceforge.net Summary : Data for The Ur-Quan Masters Description : The Ur-Quan Masters is a port of the 3DO version of Star Control 2. =2D-=3D-=3D-=3D * Mon Dec 09 2002 Guillaume Rousse <g.r...@li...> 0.1-1mdk =2D initial mdk package, based on Ville Skytt=E4 <ville.skytta at iki.fi> w= ork =2D-=3D-=3D-=3D =2D-=3D-=3D-=3D =2D-=3D-=3D-=3D =2D- http://www.mandrake-linux.com/en/cookerdevel.php3 |
|
From: Kevin W. <kw...@ea...> - 2002-12-09 03:32:52
|
In current CVS, there are some planets on which the coarse scan clear=20 still misses a portion of the text (for example Alpha Pavonis VII, part=20 of the '2' can still be seen when you leave the scan menu). Attached [trivial] patch for scan.c fixes it (at lest for that specific=20 case). - Kevin W --=20 Kevin Worcester kw...@ea... http://home.earthlink.net/~kworces/ |
|
From: TD <td...@pa...> - 2002-12-07 07:18:59
|
I'm rather new to C (learning quickly though) but loved playing Starcon = 2 and want to help out. Anyway I fixed two bugs I noticed and thought I = could managed :) According to the Changelog loci fixed it so that the modules were = horizontally aligned correctly but I noticed they were also 1 pixel too = high as well. Also the thrusters and jets were 1 pixel to the left as = well. Index: sis.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsroot/sc2/sc2/src/sc2code/sis.c,v retrieving revision 1.9 diff -r1.9 sis.c 527c527,528 < s.origin.x =3D s.origin.y =3D 0; --- > s.origin.x =3D 1; > s.origin.y =3D 0; 563c564 < s.origin.y =3D 0; --- > s.origin.y =3D 1; And in the initial menu up was down and down was up. Index: restart.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsroot/sc2/sc2/src/sc2code/restart.c,v retrieving revision 1.5 diff -r1.5 restart.c 119,120c119,120 < if (GetInputXComponent (InputState) < 0 < || GetInputYComponent (InputState) < 0) --- > if (GetInputXComponent (InputState) > 0 > || GetInputYComponent (InputState) > 0) 125,126c125,126 < else if (GetInputXComponent (InputState) > 0 < || GetInputYComponent (InputState) > 0) --- > else if (GetInputXComponent (InputState) < 0 > || GetInputYComponent (InputState) < 0) -TD |
|
From: Serge v. d. B. <sv...@st...> - 2002-12-07 00:55:15
|
On Sat, 7 Dec 2002, Max Horn wrote:
> >I don't see why SDL even does it that way; a library can itself arrange
> >for an initialisation function to be called before main(). At least using
> >gcc, but other compilers probably too.
> That's not enough in this case, though, we have to be able to call
> the actual main function, and clean up after it, too.
>
> Providing __init / __fini symbols wouldn't work: first off, the order
> of their calls would then have to be precisely right. Secondly,
> before we can call the "real" main, we have to call into the OS, and
> let the OS main runloop take over. Which will then in turn call an
> object we created, which in turn invokes the application's main
> method in a callback...
> If you think this sounds rather nasty, you are right. But the
> relatively modern event system of Cocoa is simply very different from
> the more simplistic model used in SDL, so we have to bend a lot to
> get a match.
Ok, in that case, what about an option to 'sdl-config --libs' to
change the entry function to your own? ('-W,-e,SDL_Main' for gcc/ld).
Serge
|
|
From: Max H. <ma...@qu...> - 2002-12-07 00:43:54
|
At 1:24 Uhr +0100 07.12.2002, Serge van den Boom wrote: >On Thu, 5 Dec 2002, Max Horn wrote: >> On OSX, starcon2.c *MUST* #include <SDL.h>. >> >> The reason is that before the normal main(), a special SDL provide >> main must be run, to setup various things, and run a Cooca runloop >> (feel free to ask for details, I wrote a good part of that code :-). >> To this end, SDL.h has a #define main SDL_main in it. >> >> The simple fix is to insert >> #include <SDL.h> >> into starcon2.c. I hope this breaks no other system (in fact I don't >> see why it should). >I will commit this, as there seems to be no other choice. >I would have liked to keep SDL and the main program seperate. >I don't see why SDL even does it that way; a library can itself arrange >for an initialisation function to be called before main(). At least using >gcc, but other compilers probably too. That's not enough in this case, though, we have to be able to call the actual main function, and clean up after it, too. Providing __init / __fini symbols wouldn't work: first off, the order of their calls would then have to be precisely right. Secondly, before we can call the "real" main, we have to call into the OS, and let the OS main runloop take over. Which will then in turn call an object we created, which in turn invokes the application's main method in a callback... If you think this sounds rather nasty, you are right. But the relatively modern event system of Cocoa is simply very different from the more simplistic model used in SDL, so we have to bend a lot to get a match. Max -- ----------------------------------------------- Max Horn Software Developer |
|
From: Serge v. d. B. <sv...@st...> - 2002-12-07 00:24:43
|
On Thu, 5 Dec 2002, Max Horn wrote: > On OSX, starcon2.c *MUST* #include <SDL.h>. > > The reason is that before the normal main(), a special SDL provide > main must be run, to setup various things, and run a Cooca runloop > (feel free to ask for details, I wrote a good part of that code :-). > To this end, SDL.h has a #define main SDL_main in it. > > The simple fix is to insert > #include <SDL.h> > into starcon2.c. I hope this breaks no other system (in fact I don't > see why it should). I will commit this, as there seems to be no other choice. I would have liked to keep SDL and the main program seperate. I don't see why SDL even does it that way; a library can itself arrange for an initialisation function to be called before main(). At least using gcc, but other compilers probably too. Serge |
|
From: Abaddon <ab...@80...> - 2002-12-06 19:27:59
|
short answer...ask one of the core developers for a long answer which im sure they have... cvs diff -u > patch_name.diff --Abaddon On Fri, 2002-12-06 at 13:12, P Tran wrote: > Do you guys have any instructions on how to create a patch? >=20 >=20 >=20 > ______________________________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now |
|
From: Abaddon <ab...@80...> - 2002-12-06 19:12:48
|
look, i agree with everything you've said, and i will apply fixes however you want, in the mean time apply the first round of patches, then tell me what you want done, because im not going to go off, do it one way which i think is perfectly reasonable, and then have everyone say no when im done...tell me the way that will make you happy and ill do it that way, once and for all, i have no problem doing that, but i do need to know up front what you would find amicable... --Abaddon On Fri, 2002-12-06 at 14:04, Serge van den Boom wrote: > On 6 Dec 2002, Abaddon wrote: > > ok, heres the thing...these fixes are to effect stability, in a proper > > running environment they should never overrun anyways, and up to this > > point everyone has been just hoping that was the case...these patches > > are just to effect stability...more to the point they are to make the > > propagation of bugs harder... > > > > the original code doesn't even check to see if its going to fit, with > > these patches it will always fit, it might crash a second later if its > > not null terminated but it didn't trash your stack or your heap...the > > problem is that this often doesn't crash the system but causes data > > corruption... > Yeah, I understand this must be annoying to you. And I agree that the sor= t > of incorrect behaviour caused by cut off strings is usually easier to deb= ug > than that caused by a corrupted heap. However, wasn't the idea of these > patches to get these things fixed once and for all? >=20 > If you don't want to fix this, I'll apply your previous patches, as they > ARE better than what we have right now, but I'd be much happier if you'd > take another look at it. It's your choice. >=20 > > tell you what, you guys decide how you want this fixed and ill fix it, > I'd like to see too long strings be detected and handled. > How you do it, I don't mind much. The stuff I mentioned in my previous ma= il > were only suggestions. (just keep in mind it needs to run on various > platforms). >=20 > > but when you do finally decide how this is best fixed, please please > > please please, make sure everyone from then on out follows the > > conventions because these patches, > We've got the 'Contributing' file now for precisely this reason. >=20 > Serge >=20 >=20 > Btw, I'm at the moment catching up with some other work I should have don= e > before, when I was working on UQM. Don't expect me to have much time to d= o > many commits for a few days. >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Sc2-devel mailing list > Sc2...@li... > https://lists.sourceforge.net/lists/listinfo/sc2-devel >=20 |
|
From: Serge v. d. B. <sv...@st...> - 2002-12-06 19:04:12
|
On 6 Dec 2002, Abaddon wrote: > ok, heres the thing...these fixes are to effect stability, in a proper > running environment they should never overrun anyways, and up to this > point everyone has been just hoping that was the case...these patches > are just to effect stability...more to the point they are to make the > propagation of bugs harder... > > the original code doesn't even check to see if its going to fit, with > these patches it will always fit, it might crash a second later if its > not null terminated but it didn't trash your stack or your heap...the > problem is that this often doesn't crash the system but causes data > corruption... Yeah, I understand this must be annoying to you. And I agree that the sort of incorrect behaviour caused by cut off strings is usually easier to debug than that caused by a corrupted heap. However, wasn't the idea of these patches to get these things fixed once and for all? If you don't want to fix this, I'll apply your previous patches, as they ARE better than what we have right now, but I'd be much happier if you'd take another look at it. It's your choice. > tell you what, you guys decide how you want this fixed and ill fix it, I'd like to see too long strings be detected and handled. How you do it, I don't mind much. The stuff I mentioned in my previous mail were only suggestions. (just keep in mind it needs to run on various platforms). > but when you do finally decide how this is best fixed, please please > please please, make sure everyone from then on out follows the > conventions because these patches, We've got the 'Contributing' file now for precisely this reason. Serge Btw, I'm at the moment catching up with some other work I should have done before, when I was working on UQM. Don't expect me to have much time to do many commits for a few days. |
|
From: Abaddon <ab...@80...> - 2002-12-06 18:15:22
|
ok, heres the thing...these fixes are to effect stability, in a proper running environment they should never overrun anyways, and up to this point everyone has been just hoping that was the case...these patches are just to effect stability...more to the point they are to make the propagation of bugs harder... the original code doesn't even check to see if its going to fit, with these patches it will always fit, it might crash a second later if its not null terminated but it didn't trash your stack or your heap...the problem is that this often doesn't crash the system but causes data corruption... tell you what, you guys decide how you want this fixed and ill fix it, until then these patches are far far better than just not checking... but when you do finally decide how this is best fixed, please please please please, make sure everyone from then on out follows the conventions because these patches, while i am more than happy to do them, are very time consuming, boring, and tedious to make and test... --Abaddon |
|
From: P T. <rog...@ya...> - 2002-12-06 18:12:07
|
Do you guys have any instructions on how to create a patch? --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now |
|
From: Abaddon <ab...@80...> - 2002-12-06 17:57:54
|
done... --Abaddon On Fri, 2002-12-06 at 05:01, Serge van den Boom wrote: > On 6 Dec 2002, Abaddon wrote: > > same as last patch but for strcpy > strncpy does not null-terminate if the string is too short. This one needs > work. > > Serge > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Sc2-devel mailing list > Sc2...@li... > https://lists.sourceforge.net/lists/listinfo/sc2-devel > |
333 messages has been excluded from this view by a project administrator.
