Tuesday, February 13, 2007
Friday, February 09, 2007
On the evils of _SECURE_SCL
När vi bytte till VS2005 på jobbet upptäckte vi snabbt att våra gamla kära STL-containers hade blivit rövlångsamma. Efter lite surfande fick vi reda på att Microsoft hade lagt in en massa bounds-checkar i exempelvis std::vector. Som default! I RELEASEBYGGEN!1! Hade vi haft anledning att tro att vi regelbundet skulle skriva utanför vectorer i testad release-kod hade vi använt Java eller Basic...
Vi upptäckte dock som tur var att man snabbt och enkelt kunde stänga av checkarna genom att definera _SECURE_SCL=0 innan man inkluderar stl-headerserna.
Cue till idag, 6 månader senare. Jag har just suttit 5 dagar och debuggat en lömsk bug som gör att simpel stl-kod kraschar på oförutsägbara sätt. Idag hittade jag problemet; ett externt lib var byggt utan _SECURE_SCL=1. Ridå.
Min lösning är att lägga till följande i början av den globala vector includefilen:
#if _SECURE_SCL && defined(NDEBUG)
#error Using _SECURE_SCL in release code is fraught with peril!
#endif
Tips till Microsoft: hitta på ett sätt att detektera när man försöker länka moduler med olika _SECURE_SCL-status. Avbryt då länkningen. Och be om ursäkt...
Vi upptäckte dock som tur var att man snabbt och enkelt kunde stänga av checkarna genom att definera _SECURE_SCL=0 innan man inkluderar stl-headerserna.
Cue till idag, 6 månader senare. Jag har just suttit 5 dagar och debuggat en lömsk bug som gör att simpel stl-kod kraschar på oförutsägbara sätt. Idag hittade jag problemet; ett externt lib var byggt utan _SECURE_SCL=1. Ridå.
Min lösning är att lägga till följande i början av den globala vector includefilen:
#if _SECURE_SCL && defined(NDEBUG)
#error Using _SECURE_SCL in release code is fraught with peril!
#endif
Tips till Microsoft: hitta på ett sätt att detektera när man försöker länka moduler med olika _SECURE_SCL-status. Avbryt då länkningen. Och be om ursäkt...