[C/Visual C++] Problemen met compilen in Release mode

[cobratbq]

Ik zit met een vaag probleem te kijken als ik het programmatje wat ik geschreven heb in Release mode compile. Het programma is in C geschreven omdat ik het ook in dos nodig heb, maar ik compile ook een Win32 versie voor onder windows. Heb ik meer vertrouwen in als ik het onder Windows gebruik.
Nu compile ik het programma tijdens het testen in Debug mode. Dan gaat alles goed en kan ik eigenlijk niets ontdekken wat verkeerd gaat. Ik krijg echter wel 5 warnings, maar niets van dergelijke belangrijkheid dat de boel in Release mode over de zeik gaat.
Het grote probleem krijg ik wanneer ik het programma gecompiled heb in Release mode.
Tijdens het gebruik van het programma verandert er zomaar tijdens het gebruik een variabele en staat er in plaats van een dir-path een 'fs]'. Maar omdat er niets in de code is die daartoe aanleiding kan geven, vraag ik me toch af hoe dat zit.
Verder heb ik dezelfde code ook in BC3.1 gecompiled en dan heb ik nergens last van. En in debug mode is alles ook gewoon prima.
Het raarste vind ik nog dat diezelfde rits code meerdere malen afgelopen wordt en ik heb slechts in 1 van de loops problemen.
Weet iemand waar dat aan kan liggen, want ik ben nog niet zo bekend met Visual C++ (Visual C++ .NET om precies te zijn) maar ik heb het probleem al meerdere malen gehad.

[EfBe]

99.9% van de gevallen is het een uninitialized variable die je gebruikt in een expressie. In debug mode, worden alle variables op 0/null geinitialiseerd, maar in release build niet. Hierdoor kun je problemen krijgen.

In de 0.1% van de gevallen betreft het bugs in de optimizer, oftewel, door het optimizen zijn er foutjes in geslopen.

Je zult eerst je code na moeten lopen of je nergens een parameter gebruikt die je niet eerst initialiseert op een bepaalde waarde. Als dat allemaal ok is, en je hebt nog steeds dezelfde errors, compileer in release mode maar zonder optimizations (kun je uitzetten). Als het dan goed werkt, zet dan per keer een optimize-optie aan en kijk wat er gebeurt. Veelal heb je dan zo de optimize stap te pakken die je nekt, maar zoals gezegd, veelal is het uninitialized parameter gebruik.

[whoami]

Hmm. Ik zorg er altijd voor dat m'n programma's compilen met 0 warnings, 0 hints.

In welke taal is dat programma nu eigenlijk geschreven? C, C++ of C++.NET ?

Als je wil dat het programma nog onder DOS draait, en je hebt het in VC++.NET geschreven, dan heb je op die pc de .NET runtime nodig, en ik denk niet dat die werkt onder DOS.
(Je kan ook programma's schrijven in C++ die onder DOS draaien, dat moet geen C zijn hoor).

[nohtml]

EfBe schreef op 26 December 2002 @ 23:06:
99.9% van de gevallen is het een uninitialized variable die je gebruikt in een expressie. In debug mode, worden alle variables op 0/null geinitialiseerd, maar in release build niet. Hierdoor kun je problemen krijgen.

Als het programma met behulp van VC++.NET gecompiled werd (in 'safe' mode), dan moeten alle variablen door de programmeur zelf geinitialiseerd worden, anders compiled het niet.
In ieder geval is het een goed idee om zowiezo alle variablen te initialiseren alvorens je ze gebruikt.
Het is ook een goed idee om ervoor te zorgen dat jouw app compiled zonder warnings en hints.

[ Voor 48% gewijzigd door whoami op 26-12-2002 23:38 ]

[EfBe]

whoami: inderdaad is het zo dat je een warning krijgt bij uninitialized gebruik van een variable, maar bv met VC++6 heb ik vaak genoeg gehad dat een variable ertussendoor slipte, en toch geen warning opleverde maar wel de release build om zeep hielp Het is inderdaad aan te bevelen t.a.t. () te zorgen dat je programma zonder warnings compileert.

[hobbit_be]

en dan nog lekker de warning level verlagen ... of gewoon geen warning alleen errors... hmmm Warning Int To Bool conversion

[curry684]

EfBe schreef op 26 December 2002 @ 23:06:
99.9% van de gevallen is het een uninitialized variable die je gebruikt in een expressie. In debug mode, worden alle variables op 0/null geinitialiseerd, maar in release build niet. Hierdoor kun je problemen krijgen.

Je vergeet timing issues, synchronizatielulligheden die in de langzame debugbuild niet (of juist wel) fout gaan en in de snelle releasebuild wel (of juist niet).

In de 0.1% van de gevallen betreft het bugs in de optimizer, oftewel, door het optimizen zijn er foutjes in geslopen.

Nooit van gehoord... compiler recht het raam uit knikkeren als het je overkomt, want die kan dus per definitie geen stabiele software afleveren.

[Verwijderd]

EfBe schreef op 26 december 2002 @ 23:06:
99.9% van de gevallen is het een uninitialized variable die je gebruikt in een expressie. In debug mode, worden alle variables op 0/null geinitialiseerd, maar in release build niet. Hierdoor kun je problemen krijgen.

Juist andersom dus... in debugmode init ie alles op 0xcdcdcd zodat je snel 'n niet geinite var kan herkennen in je watch window, in release mode init ie alles netjes op 0.

[EfBe]

curry684 schreef op 27 december 2002 @ 15:52:
[...]
Je vergeet timing issues, synchronizatielulligheden die in de langzame debugbuild niet (of juist wel) fout gaan en in de snelle releasebuild wel (of juist niet).

Oh ja, klopt, maar ik ging niet uit van multi-threaded eerlijkgezegd, maar inderdaad, timingissues spelen ook een rol (alhoewel je dan wel mag kijken naar je ontwerp, want dat deugt dan van geen kant)

[...]
Nooit van gehoord... compiler recht het raam uit knikkeren als het je overkomt, want die kan dus per definitie geen stabiele software afleveren.

Dit heeft me parten gespeeld in VC++ 6 en een multithreaded app. Bleek een routine te zijn die niet goed werd gecompileerd, herschreven, toen werkte het wel.

[EfBe]

Verwijderd schreef op 27 december 2002 @ 17:02:
[...]
Juist andersom dus... in debugmode init ie alles op 0xcdcdcd zodat je snel 'n niet geinite var kan herkennen in je watch window, in release mode init ie alles netjes op 0.

Weet je dat zeker? Bij mijn weten is het zo dat in debugmode alles geinit wordt. Maar het is alweer een tijdje geleden...

[Verwijderd]

EfBe schreef op 27 December 2002 @ 17:27:
[...]Weet je dat zeker? Bij mijn weten is het zo dat in debugmode alles geinit wordt. Maar het is alweer een tijdje geleden...

Ja dat weet ik zeker

Table 1. Potential patterns Pattern Description
0xFDFDFDFD No man's land (normally outside of a process)
0xDDDDDDDD Freed memory
0xCDCDCDCD Uninitialized (global)
0xCCCCCCCC Uninitialized locals (on the stack)

bron

[Verwijderd]

>Nooit van gehoord... compiler recht het raam uit knikkeren als het je overkomt,
>want die kan dus per definitie geen stabiele software afleveren

Tjonge, wat zou jij weinig compilers overhouden dan
Ik weet niet hoor, maar ik denk dat we op m'n werk 't afgelopen jaar wel een bugje of 50 hebben gevonden per compiler die we gebruiken.
(GCC, VC++)

Vorige week weer 2 bugs in de VC-compiler gevonden.

Ik denk dat je niet in een productie-omgeving werkt ?

[EfBe]

Verwijderd schreef op 27 december 2002 @ 17:38:
[...]
Ja dat weet ik zeker

Table 1. Potential patterns Pattern Description
0xFDFDFDFD No man's land (normally outside of a process)
0xDDDDDDDD Freed memory
0xCDCDCDCD Uninitialized (global)
0xCCCCCCCC Uninitialized locals (on the stack)

bron

Ik heb even een klein testje gedaan in VC++7:
int *pInt;
printf("value of pInt: %x\n", pInt);

in debugmode is het: 0xCCCCCCCC
in releasemode is het: 0x41400000 (oftewel random waarde)

In VC6 exact hetzelfde, alleen dan andere random waarde.

Je hebt dus idd gelijk, ik niet, vwb de debugbuilds. Voor de releasemode builds echter worden de variables niet geinitialiseerd op 0, wat jij wel beweerde. (detail ).

[cobratbq]

Tnx, ga eens op onderzoek uit.

Het is trouwens C code. Kan het zijn dat die compiler er niet goed mee overweg kan omdattie graag c++ wil hebben?
Het is maar een idee hoor, maar dat vroeg ik me gewoon af, want m'n ouwe bc3.1 heeft nergens moeite mee.

[Verwijderd]

is't veel code? anders post je 't hier of zet je 'n zipje online dan kijken we even mee?

[curry684]

cobratbq schreef op 27 December 2002 @ 21:03:
Het is trouwens C code. Kan het zijn dat die compiler er niet goed mee overweg kan omdattie graag c++ wil hebben?
Het is maar een idee hoor, maar dat vroeg ik me gewoon af, want m'n ouwe bc3.1 heeft nergens moeite mee.

VS besluit aan de hand van de extensie welke compilemode ie ingaat, voor .c gaat ie op C-mode en .c* op C++-modus. Dus je moet wel de extensie .c gebruiken anders krijg je geemmer.

EfBe schreef op 27 December 2002 @ 17:26:
Oh ja, klopt, maar ik ging niet uit van multi-threaded eerlijkgezegd, maar inderdaad, timingissues spelen ook een rol (alhoewel je dan wel mag kijken naar je ontwerp, want dat deugt dan van geen kant)

Of je bent gewoon een mutex vergeten te locken waardoor timing ineens wel belangrijk werd. Heeft niets met je ontwerp van doen.

Over bugs in optimizer:

Dit heeft me parten gespeeld in VC++ 6 en een multithreaded app. Bleek een routine te zijn die niet goed werd gecompileerd, herschreven, toen werkte het wel.

Ik heb nog nooit problemen in VC++ 6 of 7 aangetroffen die spontane onverklaarbare knallers veroorzaakten in applicaties. Ik ben dan ook erg benieuwd hoe jullie aan het bewijs zijn gekomen dat de compiler schuldig is en niet jullie originele implementatie.

EfBe schreef op 27 December 2002 @ 19:17:
[...]

Ik heb even een klein testje gedaan in VC++7:
int *pInt;
printf("value of pInt: %x\n", pInt);

in debugmode is het: 0xCCCCCCCC
in releasemode is het: 0x41400000 (oftewel random waarde)

In VC6 exact hetzelfde, alleen dan andere random waarde.

Je hebt dus idd gelijk, ik niet, vwb de debugbuilds. Voor de releasemode builds echter worden de variables niet geinitialiseerd op 0, wat jij wel beweerde. (detail ).

Yarvieh had deels gelijk: de process-space van een releasebuild wordt op 0 geinitialiseerd, en dus de stack ook. Dit gebeurt echter alleen bij het opstarten van het proces, daarna is het 'vervuil maar raak'. Een ongeinitialiseerde lokale variabele zal gewoon de vorige waarde bevatten die er op die plek gepushed is geweest. Meestal poep dus.

Verwijderd schreef op 27 December 2002 @ 17:52:
>Nooit van gehoord... compiler recht het raam uit knikkeren als het je overkomt,
>want die kan dus per definitie geen stabiele software afleveren
Tjonge, wat zou jij weinig compilers overhouden dan
Ik weet niet hoor, maar ik denk dat we op m'n werk 't afgelopen jaar wel een bugje of 50 hebben gevonden per compiler die we gebruiken.
(GCC, VC++)

Sja ik denk toch echt dat dat eerder bij jou ligt dan bij die compilers. Als ik iedere onverklaarbare knaller in m'n programmatuur aan de compiler toe zou schrijven kom ik echt wel aan de 50 per jaar ja, maar over het algemeen blijkt toch wel dat de compiler het aan het rechte eind heeft na scrutineuze inspectie van de geproduceerde assemblercode. En dan zit ik voor wat VC6 en 7 betreft toch echt nog steeds onder de 5 compilerbugs na 4 jaar werken in een productieomgeving.

Ik denk dat je niet in een productie-omgeving werkt ?

Lees eens profiles en post-histories voordat je onzin uitkraamt

(en nee een smiley is geen open excuus om de grootste nonsens te mogen blaten)

[.oisyn]

Verwijderd schreef op 27 December 2002 @ 17:52:
Vorige week weer 2 bugs in de VC-compiler gevonden.

ICEs zijn een ding, foute machinecode generatie is echter heel wat anders

[Soultaker]

curry684 schreef op 27 December 2002 @ 15:52:
Je vergeet timing issues, synchronizatielulligheden die in de langzame debugbuild niet (of juist wel) fout gaan en in de snelle releasebuild wel (of juist niet).

[...]

Nooit van gehoord... compiler recht het raam uit knikkeren als het je overkomt, want die kan dus per definitie geen stabiele software afleveren.

Wijze woorden (zowel de eerste opmerking als de tweede)!

Overigens heb ik ook wel eens heel sporadisch last van dit fenomeen en soms weet ik de fout in mijn eigen code niet te vinden; in dat geval herschrijf ik de code in kwestie meestal helemaal. Ik ga er altijd van uit dat de fout in mijn eigen code zit, anders kan ik er nooit meer van op aan dat ik een goed programma heb geschreven.

Het wil trouwens ook nog regelmatig voorkomen met Visual C++ en de GNU compiler, dat er bij het compileren 'internal compiler errors' en dergelijke optreden. Ook in dat geval is de code herschrijven (anders formuleren) meestal de oplossing, maar dit vind ik acceptabele bugs, aangezien ze tenminste niet tot foutieve executie kunnen leiden. Dat heeft trouwens ook niets met het verschil tussen debug of release builds te maken, voor zover ik heb gemerkt.

Mijn advies aan de topic starter (en anderen die wel eens met Visual C++ werken) is dan ook om regelmatig de release builds te maken en uit te proberen (al is 't maar oppervlakkig). Dan kun je de fouten nog tijdig detecteren en isoleren. Vergeet ook niet dat in debug-modus soms andere code gegeneerd wordt (pas op voor assertions met relevante side-effects, enzovoorts).

[.oisyn]

Heisenbugs zijn ook leuk

[curry684]

Soultaker schreef op 27 December 2002 @ 21:57:
Het wil trouwens ook nog regelmatig voorkomen met Visual C++ en de GNU compiler, dat er bij het compileren 'internal compiler errors' en dergelijke optreden. Ook in dat geval is de code herschrijven (anders formuleren) meestal de oplossing, maar dit vind ik acceptabele bugs, aangezien ze tenminste niet tot foutieve executie kunnen leiden. Dat heeft trouwens ook niets met het verschil tussen debug of release builds te maken, voor zover ik heb gemerkt.

Sommige ICE's willen ook nog wel eens exit zijn na een full rebuild (bij errors in de precompiled headers bijv.), de IDE opnieuw opstarten, of gewoon een full reboot van het systeem (in die volgorde uitproberen ).

[EfBe]

curry684 schreef op 27 december 2002 @ 21:20:
Over bugs in optimizer:
[...]
Ik heb nog nooit problemen in VC++ 6 of 7 aangetroffen die spontane onverklaarbare knallers veroorzaakten in applicaties. Ik ben dan ook erg benieuwd hoe jullie aan het bewijs zijn gekomen dat de compiler schuldig is en niet jullie originele implementatie.

Een willekeurige crash middenin een routine, in releasebuild wel, in debug niet, optimizations uit bij release build -> geen crash, alle optimizations aan -> wel crash. Enfin, routine herschreven, werken. Naja, boeie verder

[...]
Yarvieh had deels gelijk: de process-space van een releasebuild wordt op 0 geinitialiseerd, en dus de stack ook. Dit gebeurt echter alleen bij het opstarten van het proces, daarna is het 'vervuil maar raak'. Een ongeinitialiseerde lokale variabele zal gewoon de vorige waarde bevatten die er op die plek gepushed is geweest. Meestal poep dus.

Err, local variables in een routine krijgen van de compiler een plaats in het stackframe, dit waren local variables. Ik wil niet mierenneukerig overkomen, maar de var was niet geinitialiseerd op 0, dus het stackframe was niet geinitialiseerd op 0 (wel in debugmode op ccccccc)

[.oisyn]

EfBe schreef op 27 december 2002 @ 22:26:
Err, local variables in een routine krijgen van de compiler een plaats in het stackframe, dit waren local variables. Ik wil niet mierenneukerig overkomen, maar de var was niet geinitialiseerd op 0, dus het stackframe was niet geinitialiseerd op 0 (wel in debugmode op ccccccc)

de stackframe wordt ook niet geinitializeerd, de stack space wordt geinitializeerd (voordat je programme begint te lopen dus). Daarna wordt het gewoon vervuild door je programma

[EfBe]

.oisyn schreef op 27 december 2002 @ 22:44:
de stackframe wordt ook niet geinitializeerd, de stack space wordt geinitializeerd (voordat je programme begint te lopen dus). Daarna wordt het gewoon vervuild door je programma

Yavier wilde toch echt doen geloven dat variabelen op 0 werden gezet, wat niet zo is. (en wat dus bugs kan veroorzaken, alhoewel je wel erg blind moet zijn wil je die warnings niet zien )

En wat is 'stackspace' ? Bij mijn weten is dat de x-KB die het proces toegewezen krijgt voor zn stack, waar dus ook de stackframes in staan. (uberhaupt kun je je afvragen waarom een stackspace wordt geinitialiseerd, wanneer je daarbinnen altijd eerst schrijft voordat je leest)

Naja, dit wordt wel wat drammerig zo en gaat wel erg offtopic.

[Verwijderd]

(uberhaupt kun je je afvragen waarom een stackspace wordt geinitialiseerd, wanneer je daarbinnen altijd eerst schrijft voordat je leest)

Dat is een security-iets. Alle geheugen die je krijgt van het systeem (let op: 'van het systeem', dus niet noodzakelijk uit je heap/stack) wordt op 0 geinitialiseerd omdat het systeem niet weet of in dat geheugen belangrijke of security gevoelige gegevens als administrator passwords ofzo stonden. Ik heb van horen zeggen dat win9x dat niet doet, maar dat heb ik nooit uitgeprobeerd. (Loop altijd met een wijde boog om 9x en alle bijbehorende ellende heen)

[EfBe]

Qlone: snap ik, maar er wordt geen 0 ingeschreven maar andere bagger (0xDDDDDDDD meen ik). Waar het mij om ging, in mn initiele (en naar later bleek mega-foute) bewering was dat, de developer aannames doet van 'zo zal de initiele staat van mn variabelen/memory etc zijn' terwijl dat niet klopt.

[.oisyn]

[nohtml]

EfBe schreef op 28 december 2002 @ 01:12:
[...]

Yavier wilde toch echt doen geloven dat variabelen op 0 werden gezet, wat niet zo is. (en wat dus bugs kan veroorzaken, alhoewel je wel erg blind moet zijn wil je die warnings niet zien )

Je reageerde op curry684 alsof ie ongelijk had, terwijl jij het over stackframes had en curry over de algemene process-space (waar de stack space dus bij inbegrepen zat). Ik hielp dat misverstand even uit de weg . Het klopt idd niet dan in release builds in VC++ de locale variabelen default geinitializeerd worden

En wat is 'stackspace' ? Bij mijn weten is dat de x-KB die het proces toegewezen krijgt voor zn stack, waar dus ook de stackframes in staan. (uberhaupt kun je je afvragen waarom een stackspace wordt geinitialiseerd, wanneer je daarbinnen altijd eerst schrijft voordat je leest)

juist, en die wordt geinitializeerd op 0. Er wordt zeker niet eerst geschreven; als je een lokale variabele hebt die je niet meteen initializeert kun je m dus uitlezen voor je m schrijft . Op die manier kan een functie dus vlak na de start van je programma de juiste resultaten opleveren, terwijl ie na een tijdje verkeerde resultaten retourneert omdat er dan rotzooi op de stack staat

[EfBe]

oisyn: ok zijn we het eens (nu het probleem van TS nog )

[ Voor 36% gewijzigd door EfBe op 28-12-2002 09:50 ]

[cobratbq]

Ik heb nog niks uitgetest op andere pc, maar ik denk dat ik al weet wat het probleem is. Ik heb tot 5 keer toe een pointer naar een char-array geretourneerd. Ja en dat werkt idd de eerste keer wel, maar omdat die lokale variabele verwijderd wordt voordattie aangesproken is dat niet altijd een suc6. Ik denk dat bij mij vooral alles goed ging omdat die geheugenlocatie sowieso al apart gezet was omdat ik ook in debug-compilations aan het testen ben.

Maar ik heb het al gezien.
Ik heb al een gedeelte herschreven.
En de andere helft komt zeer binnenkort
Maar ik leer er wel een hoop van.
Tnx guys

[cobratbq]

ff voorbeeld van wat ik fout gedaan heb.

C:

char *test( .... vanalles en nog wat ... ) {
 int iets_nodig_voor_handelingen;
 char returnstring[500];

 /*Allerlei handelingen*/

 return returnstring;
} 

Da's natuurlijk stom, want een integer kannie wel returnen omdat dan heel die integer teruggegeven wordt.
Dat kan helaas niet naar een character-array. Omdat dan alleen het adres teruggegeven wordt waar de info gezocht kan worden. Vervolgens wordt die informatie weggegooid.

C:

if( Me != right )
  correct();

(of wel: Correct me if i'm wrong )

[Verwijderd]

cobratbq schreef op 28 december 2002 @ 18:06:
Dat kan helaas niet naar een character-array. Omdat dan alleen het adres teruggegeven wordt waar de info gezocht kan worden. Vervolgens wordt die informatie weggegooid.

Je kan die char array evt static maken dan kan 't wel, of 't een mooie oplossing is is 'n 2e

[.oisyn]

Er zijn in principe 2 oplossingen (naast die van Yarvieh)

de eerste is om een buffer te alloceren met malloc () en die retourneren, de andere is een buffer meegeven als parameter (en natuurlijk een parameter voor de lengte!!!), die je routine dan vult met de juiste gegevens

[curry684]

EfBe schreef op 27 december 2002 @ 19:17:
Ik heb even een klein testje gedaan in VC++7:
int *pInt;
printf("value of pInt: %x\n", pInt);

in debugmode is het: 0xCCCCCCCC
in releasemode is het: 0x41400000 (oftewel random waarde)

In VC6 exact hetzelfde, alleen dan andere random waarde.

Je hebt dus idd gelijk, ik niet, vwb de debugbuilds. Voor de releasemode builds echter worden de variables niet geinitialiseerd op 0, wat jij wel beweerde. (detail ).

Ter illustratie copy/paste ik hier ff de code die VC7 Runtimes uitvoeren om jouw main-functie aan te roepen:

C++:

#ifdef _WINMAIN_

#ifdef WPRFLAG
int wWinMainCRTStartup(
#else  /* WPRFLAG */
int WinMainCRTStartup(
#endif  /* WPRFLAG */

#else  /* _WINMAIN_ */

#ifdef WPRFLAG
int wmainCRTStartup(
#else  /* WPRFLAG */
int mainCRTStartup(
#endif  /* WPRFLAG */

#endif  /* _WINMAIN_ */
        void
        )
{
        int argc;   /* three standard arguments to main */
        _TSCHAR **argv;
        _TSCHAR **envp;

        int argret;
        int mainret;
        int managedapp;

#ifdef _WINMAIN_
        _TUCHAR *lpszCommandLine;
        STARTUPINFO StartupInfo;
#endif  /* _WINMAIN_ */

        _startupinfo    startinfo;

        /*
         * Determine if this is a managed application
         */
        managedapp = check_managed_app();

        /*
         * Guard the initialization code and the call to user's main, or
         * WinMain, function in a __try/__except statement.
         */

        __try {
            /*
             * Set __app_type properly
             */
#ifdef _WINMAIN_
            __set_app_type(_GUI_APP);
#else  /* _WINMAIN_ */
            __set_app_type(_CONSOLE_APP);
#endif  /* _WINMAIN_ */

            /*
             * Mark this module as an EXE file so that atexit/_onexit
             * will do the right thing when called, including for C++
             * d-tors.
             */
            __onexitbegin = __onexitend = (_PVFV *)(-1);

            /*
             * Propogate the _fmode and _commode variables to the DLL
             */
            *_IMP___FMODE = _fmode;
            *_IMP___COMMODE = _commode;

#ifdef _M_IX86
            /*
             * Set the local copy of the Pentium FDIV adjustment flag
             */

            _adjust_fdiv = * _imp___adjust_fdiv;
#endif  /* _M_IX86 */

            /*
             * Run the RTC initialization code for this DLL
             */
#ifdef _RTC
            _RTC_Initialize();
#endif  /* _RTC */

            /*
             * Call _setargv(), which will trigger a call to __setargv() if
             * SETARGV.OBJ is linked with the EXE.  If SETARGV.OBJ is not
             * linked with the EXE, a dummy _setargv() will be called.
             */
#ifdef WPRFLAG
            _wsetargv();
#else  /* WPRFLAG */
            _setargv();
#endif  /* WPRFLAG */

            /*
             * If the user has supplied a _matherr routine then set
             * __pusermatherr to point to it.
             */
            if ( !__defaultmatherr )
                __setusermatherr(_matherr);

#ifdef _M_IX86
            _setdefaultprecision();
#endif  /* _M_IX86 */

            /*
             * Do runtime startup initializers.
             *
             * Note: the only possible entry we'll be executing here is for
             * __lconv_init, pulled in from charmax.obj only if the EXE was
             * compiled with -J.  All other .CRT$XI* initializers are only
             * run as part of the CRT itself, and so for the CRT DLL model
             * are not found in the EXE.  For that reason, we call _initterm,
             * not _initterm_e, because __lconv_init will never return failure,
             * and _initterm_e is not exported from the CRT DLL.
             *
             * Note further that, when using the CRT DLL, executing the
             * .CRT$XI* initializers is only done for an EXE, not for a DLL
             * using the CRT DLL.  That is to make sure the -J setting for
             * the EXE is not overriden by that of any DLL.
             */
            _initterm( __xi_a, __xi_z );

#ifdef _RTC
            atexit(_RTC_Terminate);
#endif  /* _RTC */

            /*
             * Get the arguments for the call to main. Note this must be
             * done explicitly, rather than as part of the dll's
             * initialization, to implement optional expansion of wild
             * card chars in filename args
             */

#ifdef WPRFLAG
            startinfo.newmode = _newmode;

            argret = __wgetmainargs(&argc, &argv, &envp,
                                    _dowildcard, &startinfo);
#else  /* WPRFLAG */
            startinfo.newmode = _newmode;

            argret = __getmainargs(&argc, &argv, &envp,
                                   _dowildcard, &startinfo);
#endif  /* WPRFLAG */
            if (argret < 0)
                _amsg_exit(_RT_SPACEARG);


            /*
             * do C++ constructors (initializers) specific to this EXE
             */
            _initterm( __xc_a, __xc_z );

#ifdef _WINMAIN_
            /*
             * Skip past program name (first token in command line).
             * Check for and handle quoted program name.
             */
#ifdef WPRFLAG
            /* OS may not support "W" flavors */
            if (_wcmdln == NULL)
                return 255;
            lpszCommandLine = (wchar_t *)_wcmdln;
#else  /* WPRFLAG */
            lpszCommandLine = (unsigned char *)_acmdln;
#endif  /* WPRFLAG */

            if ( *lpszCommandLine == DQUOTECHAR ) {
                /*
                 * Scan, and skip over, subsequent characters until
                 * another double-quote or a null is encountered.
                 */
                while ( *++lpszCommandLine && (*lpszCommandLine
                        != DQUOTECHAR) );
                /*
                 * If we stopped on a double-quote (usual case), skip
                 * over it.
                 */
                if ( *lpszCommandLine == DQUOTECHAR )
                    lpszCommandLine++;
            }
            else {
                while (*lpszCommandLine > SPACECHAR)
                    lpszCommandLine++;
            }

            /*
             * Skip past any white space preceeding the second token.
             */
            while (*lpszCommandLine && (*lpszCommandLine <= SPACECHAR)) {
                lpszCommandLine++;
            }

            StartupInfo.dwFlags = 0;
            GetStartupInfo( &StartupInfo );

#ifdef WPRFLAG
            mainret = wWinMain(
#else  /* WPRFLAG */
            mainret = WinMain(
#endif  /* WPRFLAG */
                       GetModuleHandleA(NULL),
                       NULL,
                       lpszCommandLine,
                       StartupInfo.dwFlags & STARTF_USESHOWWINDOW
                        ? StartupInfo.wShowWindow
                        : SW_SHOWDEFAULT
                      );
#else  /* _WINMAIN_ */

#ifdef WPRFLAG
            __winitenv = envp;
            mainret = wmain(argc, argv, envp);
#else  /* WPRFLAG */
            __initenv = envp;
            mainret = main(argc, argv, envp);         // <------- HIER DUS
#endif  /* WPRFLAG */

#endif  /* _WINMAIN_ */

Volgens mij heb je tegen die tijd geen onvervuilde stack meer, wat jouw resultaten wel zal verklaren

[EfBe]

curry: ja ok , maar anyway: stel: als je als compilerbouwer zegt "in release build zijn alle variables geinit op 0", dan heb je dat maar te doen. Of de compiler code meecompileert die de initiele init totaal corrumpeerd.. tja, dan kom je als compilerbouwer je specs niet na

* EfBe is wel blij dat TS het 'lek' zo'n beetje boven heeft

[Verwijderd]

maar de compilerbouwer zegt niet de vars worden op 0 gezet.. dat was 'n foute aaname van mij

[Verwijderd]

curry684 schreef op 27 December 2002 @ 21:20:
[...]

Sja ik denk toch echt dat dat eerder bij jou ligt dan bij die compilers. Als ik iedere onverklaarbare knaller in m'n programmatuur aan de compiler toe zou schrijven kom ik echt wel aan de 50 per jaar ja, maar over het algemeen blijkt toch wel dat de compiler het aan het rechte eind heeft na scrutineuze inspectie van de geproduceerde assemblercode. En dan zit ik voor wat VC6 en 7 betreft toch echt nog steeds onder de 5 compilerbugs na 4 jaar werken in een productieomgeving.

[...]

Lees eens profiles en post-histories voordat je onzin uitkraamt

(en nee een smiley is geen open excuus om de grootste nonsens te mogen blaten)

a) Chill bro
b) Nope, *echte* compilerbugs. Ik wil je de reacties van de compiler-developers zelf wel laten lezen als je geinteresseerd bent..?
c) Tuurlijk ligt 99% van de bugs aan de programmeur. Maar hey, compilers zijn *ook* maar geprogrammeerd door programmeurs - als je 't over compiler-bugs wilt hebben is er geen mooier voorbeeld dan al dat ouwe template-gezeik van MSVC

En hey, je hoeft geen profiles of post-histories van iemand te lezen om te reageren op 1 bullshit-opmerking die die maakt - post-history of niet, 't blijft bullshit.
En speciaal voor jou - geen smilie erachter.

Oh, doe dit bv. eens :
http://www.google.nl/sear...=UTF-8&oe=UTF-8&hl=nl&lr=

Nou, laat mij eens een compiler zien waar geen bugs in zitten ..?
Want alle compilers die hier voorbij komen zou jij dus nooit van je leven gebruiken...

[Zoijar]

Verwijderd schreef op 05 January 2003 @ 19:02:
Maar hey, compilers zijn *ook* maar geprogrammeerd door programmeurs - als je 't over compiler-bugs wilt hebben is er geen mooier voorbeeld dan al dat ouwe template-gezeik van MSVC

Veel compilers worden geschreven door programmas die provably correct zijn Maar dan nog zit er wel een bugje in de gramatica

De meeste compilers bevatten idd bugs, het ligt er alleen aan hoe ernstig die zijn.
Dat sorry-excuse-for-a-c++-compiler msvc6 had flink wat taal bugs, legale C++ constructs die niet compiled werden. Op zich is dat wel vervelend maar niet zo ernstig. Wat bv VEEL erger is, is een compiler waarvan de optimizer niet thread-safe code genereerd. Of een buggy garbage collector...dat soort dingen.

[Verwijderd]

Nou, laatst een bug in GCC, krijg je na 2 weken een mailtje terug van SNSystems; ze hebben de bug gevonden hoor !
Laten ze je de fix zien :
zat er ergens iets fout in een (let op)
#define
van 40 regels lang !! Die zelf uiteraard weer veel andere defines aanriep die ook tussen de 5 en 30 regels lang waren !

Christ, je zult dat maar moeten debuggen als compilerbouwer/onderhouder
Hoop dat ze die meuk snel dumpen...