Sharing some humour
-
I was doing a job for a company and they don't allow memory allocations to be used you have to request a static block at program start from the memory management unit and then recycle that in your code. You want more there is a whole song and dance you must do. It was a complete pain and then they made the mistake of telling me I could use threads and you could request space for the thread ... so I did apply for 1 thread and got given it. I offer perhaps the funniest use of a thread ever ... in windows the code would look like this
static BOOL ReleaseThread = FALSE;
DWORD WINAPI MyThread (LPVOID lpParam){
char buffer[4096];
*(void**)lpParam = &buffer[0];
do {} while (!ReleaseThread);
return (0);
}If you haven't worked it out here would be the equivalent windows use of the thread.
char* buf = NULL;
HANDLE myThread = CreateThread(0, 0, MyThread, &buf, 0, NULL);
while (!buf) {};
strcpy_s(buf, 4096, "Hello there stack buffer\r\n");
printf("%s", buf);
ReleaseThread = TRUE;But the best bit was it passed thru without anyone noticing.
In vino veritas
-
I was doing a job for a company and they don't allow memory allocations to be used you have to request a static block at program start from the memory management unit and then recycle that in your code. You want more there is a whole song and dance you must do. It was a complete pain and then they made the mistake of telling me I could use threads and you could request space for the thread ... so I did apply for 1 thread and got given it. I offer perhaps the funniest use of a thread ever ... in windows the code would look like this
static BOOL ReleaseThread = FALSE;
DWORD WINAPI MyThread (LPVOID lpParam){
char buffer[4096];
*(void**)lpParam = &buffer[0];
do {} while (!ReleaseThread);
return (0);
}If you haven't worked it out here would be the equivalent windows use of the thread.
char* buf = NULL;
HANDLE myThread = CreateThread(0, 0, MyThread, &buf, 0, NULL);
while (!buf) {};
strcpy_s(buf, 4096, "Hello there stack buffer\r\n");
printf("%s", buf);
ReleaseThread = TRUE;But the best bit was it passed thru without anyone noticing.
In vino veritas
-
leon de boer wrote:
But the best bit was it passed thru without anyone noticing.
Sounds like you are a program managers worse nightmare. :omg: Best Wishes, -David Delaune P.S. Wasn't me that downvoted you.
Haha yeah I would downvote myself :-) I figured I would get everything working before dealing with the buffer recycling. It takes a fair bit of work to track what buffers in use and where. What I laughed at was with all the rigor around memory handling I could do it and no-one raised an eyebrow. I mean that is a truely horrible idea. I will probably recycle one of my memory stream objects and donate it to them because I think the whole manual tracking of buffers is a bit naft and I think just as likely to create program errors as running out of memory.
In vino veritas
-
I was doing a job for a company and they don't allow memory allocations to be used you have to request a static block at program start from the memory management unit and then recycle that in your code. You want more there is a whole song and dance you must do. It was a complete pain and then they made the mistake of telling me I could use threads and you could request space for the thread ... so I did apply for 1 thread and got given it. I offer perhaps the funniest use of a thread ever ... in windows the code would look like this
static BOOL ReleaseThread = FALSE;
DWORD WINAPI MyThread (LPVOID lpParam){
char buffer[4096];
*(void**)lpParam = &buffer[0];
do {} while (!ReleaseThread);
return (0);
}If you haven't worked it out here would be the equivalent windows use of the thread.
char* buf = NULL;
HANDLE myThread = CreateThread(0, 0, MyThread, &buf, 0, NULL);
while (!buf) {};
strcpy_s(buf, 4096, "Hello there stack buffer\r\n");
printf("%s", buf);
ReleaseThread = TRUE;But the best bit was it passed thru without anyone noticing.
In vino veritas
leon de boer wrote:
they don't allow memory allocations to be used you have to request a static block at program start from the memory management unit and then recycle that in your code.
There are good reasons for that: 1. In many cases, it is better to discover that you don't have enough memory at program start than to discover it later. 2. In real-time systems, heap management time can be unpredictable. This makes achieving the time guarantees much more difficult.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
-
leon de boer wrote:
they don't allow memory allocations to be used you have to request a static block at program start from the memory management unit and then recycle that in your code.
There are good reasons for that: 1. In many cases, it is better to discover that you don't have enough memory at program start than to discover it later. 2. In real-time systems, heap management time can be unpredictable. This makes achieving the time guarantees much more difficult.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
Sorry that is not correct ... running out of memory can be fatal no matter if you allocated it before hand or ran out of it on the heap. In my case I abused the stack which is just as bad. I am an embedded programmer and I live with low ram implementations in real time systems for a living, and that was the point of my joke at those who think you can frame protection in a standard or a formula. You can't, you need to frame intent and guidelines not specific implementations. You can not create a "safe" or "perfect" specification because you haven't written the code and you don't know the problems. That whole approach is like 1960's military code specifications and nightmare movie which failed dismally and nobody really codes that way anymore we all use block based approach. The first public discussion on the new military standards in software I know of was when Boeing allowed hackers to try and hack a "little bird" unmanned helicopter. If you don't know about this stuff that would be a good start point. Hacker-Proof Code Confirmed[^] As they said you can't hack it and is guaranteed to perform error-free, that isn't a claim it's a provable fact. There are links in the article to the research language F* (F-STAR) and the Project Everest which is Microsofts play in the area of trying to develop better hack free products. Most new high reliability stuff will follow down those paths for obvious reasons, they can offer guarantees something every other technique can't do.
In vino veritas
-
Sorry that is not correct ... running out of memory can be fatal no matter if you allocated it before hand or ran out of it on the heap. In my case I abused the stack which is just as bad. I am an embedded programmer and I live with low ram implementations in real time systems for a living, and that was the point of my joke at those who think you can frame protection in a standard or a formula. You can't, you need to frame intent and guidelines not specific implementations. You can not create a "safe" or "perfect" specification because you haven't written the code and you don't know the problems. That whole approach is like 1960's military code specifications and nightmare movie which failed dismally and nobody really codes that way anymore we all use block based approach. The first public discussion on the new military standards in software I know of was when Boeing allowed hackers to try and hack a "little bird" unmanned helicopter. If you don't know about this stuff that would be a good start point. Hacker-Proof Code Confirmed[^] As they said you can't hack it and is guaranteed to perform error-free, that isn't a claim it's a provable fact. There are links in the article to the research language F* (F-STAR) and the Project Everest which is Microsofts play in the area of trying to develop better hack free products. Most new high reliability stuff will follow down those paths for obvious reasons, they can offer guarantees something every other technique can't do.
In vino veritas
I stand corrected.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
-
I stand corrected.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
You are party right any system is better than none ... I understood your intent :-) Our human systems are always flawed but yeah the new HDL synthesis tool stuff is scary good. Worth playing around with if you have the time and it's fun but quite different way of programming and probably not on Visual Studio until 2050 !!!!
In vino veritas
-
Sorry that is not correct ... running out of memory can be fatal no matter if you allocated it before hand or ran out of it on the heap. In my case I abused the stack which is just as bad. I am an embedded programmer and I live with low ram implementations in real time systems for a living, and that was the point of my joke at those who think you can frame protection in a standard or a formula. You can't, you need to frame intent and guidelines not specific implementations. You can not create a "safe" or "perfect" specification because you haven't written the code and you don't know the problems. That whole approach is like 1960's military code specifications and nightmare movie which failed dismally and nobody really codes that way anymore we all use block based approach. The first public discussion on the new military standards in software I know of was when Boeing allowed hackers to try and hack a "little bird" unmanned helicopter. If you don't know about this stuff that would be a good start point. Hacker-Proof Code Confirmed[^] As they said you can't hack it and is guaranteed to perform error-free, that isn't a claim it's a provable fact. There are links in the article to the research language F* (F-STAR) and the Project Everest which is Microsofts play in the area of trying to develop better hack free products. Most new high reliability stuff will follow down those paths for obvious reasons, they can offer guarantees something every other technique can't do.
In vino veritas
Hi, I waited until the thread went beyond the first page to further engage with you. I can tell you why your employer has this requirement. This is common on mission-critical software. Exceptions and Stack Unwinding in C++[^] If you allocate memory on the stack... and a recoverable exception occurs in your thread... the memory is correctly released during stack unwinding. If you allocate memory on the heap and a recoverable exception occurs in your thread... the memory is not released and now your application potentially has a resource leak.
leon de boer wrote:
As they said you can't hack it and is guaranteed to perform error-free, that isn't a claim it's a provable fact.
This is not correct. I have met both Bryan Parno[^] and Jeannette Wing[^] and I was present at the 2014 presentation on campus at Redmond. Yes, small sections of logic can be statistically proven to be secure. It would not be correct to make the claim of "guaranteed to perform error-free, that isn't a claim it's a provable fact" If I were to assign a confidence level to what they have achieved I would say "High Confidence". Best Wishes, -David Delaune