Good point. The alternative to all of those strings is to have AllocFailure() capture the location from which it is being called and, if possible, provide some amount of stack walkback. That means there is a file of symbols and such somewhere that can be used as part of crash analysis by the developers.
I am assuming this is done in release code, although there are debugging tests where one provokes memory exhaustion to see how the application fails. - Dennis PS: For windows, Online Crash Analysis support works with that and automatically collects crash data minidumps in a database for the producers of the software to go in and see what bad things are happening with actual users. However I don't recall ever seeing a Windows Error Reporting (WER) crasher message in any use of Windows 8, so that may be a disappearing service. That or software producers are (1) paranoid about having Microsoft have so much information or (2) unwilling to receive crash data from their users in the first place. The new security technique of rearranging sections of code images on loading may have something to do with how this works nowadays, also. <https://msdn.microsoft.com/en-us/library/windows/hardware/dn641144.aspx>. -----Original Message----- From: jan i [mailto:[email protected]] Sent: Friday, February 20, 2015 01:21 To: [email protected]; Dennis Hamilton Subject: Re: Checking malloc success and adding perror() On 19 February 2015 at 20:26, Dennis E. Hamilton <[email protected]> wrote: > Some small points. > > 1. On the ability to trace where the memory allocation failed, it would > be handy to take advantage of preprocessor variables to provide origin > information relative to the source code. > > That might be (using the previous example), with a header file having > something like > > 01 void* CheckedAlloc(size_t n, char* loc) > 02 { void* p = malloc(n); > 03 if (p == NULL) > 04 AllocFailure(loc); > 05 return p; > 06 } > > 10 #define ChkAlloc(n) (CheckedAlloc((n), #__FILE__ ":" #__LINE__ )) > I would recommend not doing this, it will work, but it will make the const part of our lib explode. If we were to do it, we would need to do it, not only for this function but in general for all functions that could self terminate (or whatever we decide to do later), and that would be a huge overhead for nearly nothing. glibc used to have a stackframetrace() function, that we used heavely in gdb, the function make a stacktrace, with different information depending on if the code was compiled with debug or not. rgds jan i. [ ... ]
