When a bug isn't really a bug?
-
Hrmmm. I have some code with suspected heap corruption. I've pored over it and can't find anything. However, the modifications I've made to the codebase in an attempt to run it down have actually yielded a copy that works reliably on several devices - devices that don't use a display with an "RGB interface" bus. On any display with an RGB interface bus the device hangs as soon as it receives serial data and rebuilds the display with it. Complete hard freeze, requiring a reflash or hard reset. I might be able to work around this by switching out my lcd_init.h with something like LovyanGFX to do my last mile display communication. However, lcd_init.h has never caused me problems before. I suspect that even if switching it out "fixes" the problem, it will have more buried the bug than actually fixed it. Now here's the thing with IoT, esp when you aren't using I/O bound multithreading or anything complicated to effect the following: Every time I boot, if i call malloc and print that pointer I get back as a hex integer to the console, it will be the same value every single time (as long as the requested size is the same). If I create a thread on each core, and spit out "A" on one, and "B" on the other, I will get the same sequence of As and Bs every time, on every machine with the same chip. That makes it very much unlike development on a PC. There aren't fiddly bits in the background making things non-deterministic. The bottom line is, if I bury this bug well enough, for all practical purposes I have "fixed" it. I hate this, but I know it to be true. I don't want to use what I know to be true to move forward on this project. Burying the bug just doesn't sit right with me. But it's an option. I wouldn't be the first to do it. Far from it. Times like this call for a little Aesop Rock
Got an angel on my left shoulder, a devil on the polar Got a mug a frigid, got a mug a solar, sliiidde over The recipe's designed to plug the appetite for continuity By stitching togetherness theme congruents (beautifully) I peel back hearts and lodge greed physics in the chambers Cauterize the wound and heads like "Gimme gimme something major" Road side prophetic, ascend well (well) Enveloped in a mummy ribbon system Blistering in a wishing well BIG BANG!
I don't expect most people to understand that, but he and I communicate, even if he doesn't know it.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
-
Hrmmm. I have some code with suspected heap corruption. I've pored over it and can't find anything. However, the modifications I've made to the codebase in an attempt to run it down have actually yielded a copy that works reliably on several devices - devices that don't use a display with an "RGB interface" bus. On any display with an RGB interface bus the device hangs as soon as it receives serial data and rebuilds the display with it. Complete hard freeze, requiring a reflash or hard reset. I might be able to work around this by switching out my lcd_init.h with something like LovyanGFX to do my last mile display communication. However, lcd_init.h has never caused me problems before. I suspect that even if switching it out "fixes" the problem, it will have more buried the bug than actually fixed it. Now here's the thing with IoT, esp when you aren't using I/O bound multithreading or anything complicated to effect the following: Every time I boot, if i call malloc and print that pointer I get back as a hex integer to the console, it will be the same value every single time (as long as the requested size is the same). If I create a thread on each core, and spit out "A" on one, and "B" on the other, I will get the same sequence of As and Bs every time, on every machine with the same chip. That makes it very much unlike development on a PC. There aren't fiddly bits in the background making things non-deterministic. The bottom line is, if I bury this bug well enough, for all practical purposes I have "fixed" it. I hate this, but I know it to be true. I don't want to use what I know to be true to move forward on this project. Burying the bug just doesn't sit right with me. But it's an option. I wouldn't be the first to do it. Far from it. Times like this call for a little Aesop Rock
Got an angel on my left shoulder, a devil on the polar Got a mug a frigid, got a mug a solar, sliiidde over The recipe's designed to plug the appetite for continuity By stitching togetherness theme congruents (beautifully) I peel back hearts and lodge greed physics in the chambers Cauterize the wound and heads like "Gimme gimme something major" Road side prophetic, ascend well (well) Enveloped in a mummy ribbon system Blistering in a wishing well BIG BANG!
I don't expect most people to understand that, but he and I communicate, even if he doesn't know it.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
-
Hrmmm. I have some code with suspected heap corruption. I've pored over it and can't find anything. However, the modifications I've made to the codebase in an attempt to run it down have actually yielded a copy that works reliably on several devices - devices that don't use a display with an "RGB interface" bus. On any display with an RGB interface bus the device hangs as soon as it receives serial data and rebuilds the display with it. Complete hard freeze, requiring a reflash or hard reset. I might be able to work around this by switching out my lcd_init.h with something like LovyanGFX to do my last mile display communication. However, lcd_init.h has never caused me problems before. I suspect that even if switching it out "fixes" the problem, it will have more buried the bug than actually fixed it. Now here's the thing with IoT, esp when you aren't using I/O bound multithreading or anything complicated to effect the following: Every time I boot, if i call malloc and print that pointer I get back as a hex integer to the console, it will be the same value every single time (as long as the requested size is the same). If I create a thread on each core, and spit out "A" on one, and "B" on the other, I will get the same sequence of As and Bs every time, on every machine with the same chip. That makes it very much unlike development on a PC. There aren't fiddly bits in the background making things non-deterministic. The bottom line is, if I bury this bug well enough, for all practical purposes I have "fixed" it. I hate this, but I know it to be true. I don't want to use what I know to be true to move forward on this project. Burying the bug just doesn't sit right with me. But it's an option. I wouldn't be the first to do it. Far from it. Times like this call for a little Aesop Rock
Got an angel on my left shoulder, a devil on the polar Got a mug a frigid, got a mug a solar, sliiidde over The recipe's designed to plug the appetite for continuity By stitching togetherness theme congruents (beautifully) I peel back hearts and lodge greed physics in the chambers Cauterize the wound and heads like "Gimme gimme something major" Road side prophetic, ascend well (well) Enveloped in a mummy ribbon system Blistering in a wishing well BIG BANG!
I don't expect most people to understand that, but he and I communicate, even if he doesn't know it.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
- When it's a tick - they aren't insects at all, but the look a lot like them - they are arachnids. 2) When it's in the manual. Then it's a feature. :-D
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
Hrmmm. I have some code with suspected heap corruption. I've pored over it and can't find anything. However, the modifications I've made to the codebase in an attempt to run it down have actually yielded a copy that works reliably on several devices - devices that don't use a display with an "RGB interface" bus. On any display with an RGB interface bus the device hangs as soon as it receives serial data and rebuilds the display with it. Complete hard freeze, requiring a reflash or hard reset. I might be able to work around this by switching out my lcd_init.h with something like LovyanGFX to do my last mile display communication. However, lcd_init.h has never caused me problems before. I suspect that even if switching it out "fixes" the problem, it will have more buried the bug than actually fixed it. Now here's the thing with IoT, esp when you aren't using I/O bound multithreading or anything complicated to effect the following: Every time I boot, if i call malloc and print that pointer I get back as a hex integer to the console, it will be the same value every single time (as long as the requested size is the same). If I create a thread on each core, and spit out "A" on one, and "B" on the other, I will get the same sequence of As and Bs every time, on every machine with the same chip. That makes it very much unlike development on a PC. There aren't fiddly bits in the background making things non-deterministic. The bottom line is, if I bury this bug well enough, for all practical purposes I have "fixed" it. I hate this, but I know it to be true. I don't want to use what I know to be true to move forward on this project. Burying the bug just doesn't sit right with me. But it's an option. I wouldn't be the first to do it. Far from it. Times like this call for a little Aesop Rock
Got an angel on my left shoulder, a devil on the polar Got a mug a frigid, got a mug a solar, sliiidde over The recipe's designed to plug the appetite for continuity By stitching togetherness theme congruents (beautifully) I peel back hearts and lodge greed physics in the chambers Cauterize the wound and heads like "Gimme gimme something major" Road side prophetic, ascend well (well) Enveloped in a mummy ribbon system Blistering in a wishing well BIG BANG!
I don't expect most people to understand that, but he and I communicate, even if he doesn't know it.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
-
Well, I suppose then this is potentially not a bug, since I've been the only one complaining so far.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
-
Hrmmm. I have some code with suspected heap corruption. I've pored over it and can't find anything. However, the modifications I've made to the codebase in an attempt to run it down have actually yielded a copy that works reliably on several devices - devices that don't use a display with an "RGB interface" bus. On any display with an RGB interface bus the device hangs as soon as it receives serial data and rebuilds the display with it. Complete hard freeze, requiring a reflash or hard reset. I might be able to work around this by switching out my lcd_init.h with something like LovyanGFX to do my last mile display communication. However, lcd_init.h has never caused me problems before. I suspect that even if switching it out "fixes" the problem, it will have more buried the bug than actually fixed it. Now here's the thing with IoT, esp when you aren't using I/O bound multithreading or anything complicated to effect the following: Every time I boot, if i call malloc and print that pointer I get back as a hex integer to the console, it will be the same value every single time (as long as the requested size is the same). If I create a thread on each core, and spit out "A" on one, and "B" on the other, I will get the same sequence of As and Bs every time, on every machine with the same chip. That makes it very much unlike development on a PC. There aren't fiddly bits in the background making things non-deterministic. The bottom line is, if I bury this bug well enough, for all practical purposes I have "fixed" it. I hate this, but I know it to be true. I don't want to use what I know to be true to move forward on this project. Burying the bug just doesn't sit right with me. But it's an option. I wouldn't be the first to do it. Far from it. Times like this call for a little Aesop Rock
Got an angel on my left shoulder, a devil on the polar Got a mug a frigid, got a mug a solar, sliiidde over The recipe's designed to plug the appetite for continuity By stitching togetherness theme congruents (beautifully) I peel back hearts and lodge greed physics in the chambers Cauterize the wound and heads like "Gimme gimme something major" Road side prophetic, ascend well (well) Enveloped in a mummy ribbon system Blistering in a wishing well BIG BANG!
I don't expect most people to understand that, but he and I communicate, even if he doesn't know it.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
Some MS controls leave "artifacts" when they change from one state to another. I have to do certain things (that look like "rituals") to make them go away. I consider that an MS "bug". It's also where I wind up putting the most comments. But it is deterministic ... you just have to determine what is required to fix it.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Well, I suppose then this is potentially not a bug, since I've been the only one complaining so far.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
But you're not "nobody". :-) I realize this is probably way beyond anything I've ever produced, but maybe my naive thinking can help. Take my line of questioning for whatever it's worth. What does it take to reproduce the bug? Can you reproduce it consistently? Once you know how to reproduce it, can you come up with a way to end up with the desired results, but avoiding the path that causes the bug to surface? Can you comment out large chunks of code until the bug stops happening (assuming you know how to reproduce it consistently in the first place)? If so, can you then start uncommenting code, little-by-little until it comes up again? When that happens, comment it out once more and keep uncommenting the rest of it until everything's been restored except for the buggy part. Of course if things are chained in such a way that for function A to work, it needs the output of function B, and commenting things out as I'm suggesting might not be an option. That's my idea anyway. I hate to go in blind, but sometimes if looking at code doesn't yield any results, no matter how long and hard you look at it, removing it and adding it back one bit at a time can be useful.
-
But you're not "nobody". :-) I realize this is probably way beyond anything I've ever produced, but maybe my naive thinking can help. Take my line of questioning for whatever it's worth. What does it take to reproduce the bug? Can you reproduce it consistently? Once you know how to reproduce it, can you come up with a way to end up with the desired results, but avoiding the path that causes the bug to surface? Can you comment out large chunks of code until the bug stops happening (assuming you know how to reproduce it consistently in the first place)? If so, can you then start uncommenting code, little-by-little until it comes up again? When that happens, comment it out once more and keep uncommenting the rest of it until everything's been restored except for the buggy part. Of course if things are chained in such a way that for function A to work, it needs the output of function B, and commenting things out as I'm suggesting might not be an option. That's my idea anyway. I hate to go in blind, but sometimes if looking at code doesn't yield any results, no matter how long and hard you look at it, removing it and adding it back one bit at a time can be useful.
That's what I've been doing and why I know it's probably heap corruption. Check this out, I thought I had isolated it to a section of code. But it wasn't that code. Because undoing a different section of code, that code starts working again. It's like pushing a bubble out of a waterbed. It just keeps moving around. I've got it now where it functions as i said, on everything but RGB displays, where it completely hangs. I MIGHT be able to work around the hang, but without knowing what is causing this, even getting it to work, it still makes me uneasy.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
-
That's what I've been doing and why I know it's probably heap corruption. Check this out, I thought I had isolated it to a section of code. But it wasn't that code. Because undoing a different section of code, that code starts working again. It's like pushing a bubble out of a waterbed. It just keeps moving around. I've got it now where it functions as i said, on everything but RGB displays, where it completely hangs. I MIGHT be able to work around the hang, but without knowing what is causing this, even getting it to work, it still makes me uneasy.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
honey the codewitch wrote:
Check this out, I thought I had isolated it to a section of code. But it wasn't that code. Because undoing a different section of code, that code starts working again. It's like pushing a bubble out of a waterbed. It just keeps moving around.
Although that doesn't always happen it should not be a surprise. When you change the execution flow you are always going to change the data space of the application. That applies to stack, heap, etc. Those changes can cause an overwrite/underwrite to move in the data space. And thus the system exception will appear and disappear. Could be that it never fails after that or it could just move to a different failure point. Because it really does matter where the bad write goes.
-
Hrmmm. I have some code with suspected heap corruption. I've pored over it and can't find anything. However, the modifications I've made to the codebase in an attempt to run it down have actually yielded a copy that works reliably on several devices - devices that don't use a display with an "RGB interface" bus. On any display with an RGB interface bus the device hangs as soon as it receives serial data and rebuilds the display with it. Complete hard freeze, requiring a reflash or hard reset. I might be able to work around this by switching out my lcd_init.h with something like LovyanGFX to do my last mile display communication. However, lcd_init.h has never caused me problems before. I suspect that even if switching it out "fixes" the problem, it will have more buried the bug than actually fixed it. Now here's the thing with IoT, esp when you aren't using I/O bound multithreading or anything complicated to effect the following: Every time I boot, if i call malloc and print that pointer I get back as a hex integer to the console, it will be the same value every single time (as long as the requested size is the same). If I create a thread on each core, and spit out "A" on one, and "B" on the other, I will get the same sequence of As and Bs every time, on every machine with the same chip. That makes it very much unlike development on a PC. There aren't fiddly bits in the background making things non-deterministic. The bottom line is, if I bury this bug well enough, for all practical purposes I have "fixed" it. I hate this, but I know it to be true. I don't want to use what I know to be true to move forward on this project. Burying the bug just doesn't sit right with me. But it's an option. I wouldn't be the first to do it. Far from it. Times like this call for a little Aesop Rock
Got an angel on my left shoulder, a devil on the polar Got a mug a frigid, got a mug a solar, sliiidde over The recipe's designed to plug the appetite for continuity By stitching togetherness theme congruents (beautifully) I peel back hearts and lodge greed physics in the chambers Cauterize the wound and heads like "Gimme gimme something major" Road side prophetic, ascend well (well) Enveloped in a mummy ribbon system Blistering in a wishing well BIG BANG!
I don't expect most people to understand that, but he and I communicate, even if he doesn't know it.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
honey the codewitch wrote:
I will get the same sequence of As and Bs every time, on every machine with the same chip.
I am not a great fan of absolutes. Especially if one starts relying on them. No doubt that is true for some cases. But although I know almost nothing about embedded I do know that they have been adding more complexity over time. So seems likely that some chips either do or will start managing threads in a less deterministic way. Although you will probably be able to shop for devices where either that is true or not true.
-
honey the codewitch wrote:
I will get the same sequence of As and Bs every time, on every machine with the same chip.
I am not a great fan of absolutes. Especially if one starts relying on them. No doubt that is true for some cases. But although I know almost nothing about embedded I do know that they have been adding more complexity over time. So seems likely that some chips either do or will start managing threads in a less deterministic way. Although you will probably be able to shop for devices where either that is true or not true.
When I said every machine, I meant every machine I am targeting, and this all holds true for those.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
-
honey the codewitch wrote:
Check this out, I thought I had isolated it to a section of code. But it wasn't that code. Because undoing a different section of code, that code starts working again. It's like pushing a bubble out of a waterbed. It just keeps moving around.
Although that doesn't always happen it should not be a surprise. When you change the execution flow you are always going to change the data space of the application. That applies to stack, heap, etc. Those changes can cause an overwrite/underwrite to move in the data space. And thus the system exception will appear and disappear. Could be that it never fails after that or it could just move to a different failure point. Because it really does matter where the bad write goes.
It does. But if that bad write doesn't actually cause an issue, and the app can be tested to work under those conditions, with that particular firmware, is it worth releasing? not for anything mission critical - it's a tool to monitor your PC's temps and usage. Sort of a philosophical question if anything.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
-
Some MS controls leave "artifacts" when they change from one state to another. I have to do certain things (that look like "rituals") to make them go away. I consider that an MS "bug". It's also where I wind up putting the most comments. But it is deterministic ... you just have to determine what is required to fix it.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Gerry Schmitz wrote:
rituals
Having delved into COM, the words 'arcane' and 'obscene' both come to mind.
Software Zen:
delete this; -
Gerry Schmitz wrote:
rituals
Having delved into COM, the words 'arcane' and 'obscene' both come to mind.
Software Zen:
delete this;I was more tempted by "cargo cult programming"[^]
Mircea
-
honey the codewitch wrote:
I will get the same sequence of As and Bs every time, on every machine with the same chip.
I am not a great fan of absolutes. Especially if one starts relying on them. No doubt that is true for some cases. But although I know almost nothing about embedded I do know that they have been adding more complexity over time. So seems likely that some chips either do or will start managing threads in a less deterministic way. Although you will probably be able to shop for devices where either that is true or not true.
jschell wrote:
I am not a great fan of absolutes. Especially if one starts relying on them.
Long ago I coined the adage: "Only a novice thinks computers are deterministic machines".
Mircea
-
Hrmmm. I have some code with suspected heap corruption. I've pored over it and can't find anything. However, the modifications I've made to the codebase in an attempt to run it down have actually yielded a copy that works reliably on several devices - devices that don't use a display with an "RGB interface" bus. On any display with an RGB interface bus the device hangs as soon as it receives serial data and rebuilds the display with it. Complete hard freeze, requiring a reflash or hard reset. I might be able to work around this by switching out my lcd_init.h with something like LovyanGFX to do my last mile display communication. However, lcd_init.h has never caused me problems before. I suspect that even if switching it out "fixes" the problem, it will have more buried the bug than actually fixed it. Now here's the thing with IoT, esp when you aren't using I/O bound multithreading or anything complicated to effect the following: Every time I boot, if i call malloc and print that pointer I get back as a hex integer to the console, it will be the same value every single time (as long as the requested size is the same). If I create a thread on each core, and spit out "A" on one, and "B" on the other, I will get the same sequence of As and Bs every time, on every machine with the same chip. That makes it very much unlike development on a PC. There aren't fiddly bits in the background making things non-deterministic. The bottom line is, if I bury this bug well enough, for all practical purposes I have "fixed" it. I hate this, but I know it to be true. I don't want to use what I know to be true to move forward on this project. Burying the bug just doesn't sit right with me. But it's an option. I wouldn't be the first to do it. Far from it. Times like this call for a little Aesop Rock
Got an angel on my left shoulder, a devil on the polar Got a mug a frigid, got a mug a solar, sliiidde over The recipe's designed to plug the appetite for continuity By stitching togetherness theme congruents (beautifully) I peel back hearts and lodge greed physics in the chambers Cauterize the wound and heads like "Gimme gimme something major" Road side prophetic, ascend well (well) Enveloped in a mummy ribbon system Blistering in a wishing well BIG BANG!
I don't expect most people to understand that, but he and I communicate, even if he doesn't know it.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
It's a feature!
-
Hrmmm. I have some code with suspected heap corruption. I've pored over it and can't find anything. However, the modifications I've made to the codebase in an attempt to run it down have actually yielded a copy that works reliably on several devices - devices that don't use a display with an "RGB interface" bus. On any display with an RGB interface bus the device hangs as soon as it receives serial data and rebuilds the display with it. Complete hard freeze, requiring a reflash or hard reset. I might be able to work around this by switching out my lcd_init.h with something like LovyanGFX to do my last mile display communication. However, lcd_init.h has never caused me problems before. I suspect that even if switching it out "fixes" the problem, it will have more buried the bug than actually fixed it. Now here's the thing with IoT, esp when you aren't using I/O bound multithreading or anything complicated to effect the following: Every time I boot, if i call malloc and print that pointer I get back as a hex integer to the console, it will be the same value every single time (as long as the requested size is the same). If I create a thread on each core, and spit out "A" on one, and "B" on the other, I will get the same sequence of As and Bs every time, on every machine with the same chip. That makes it very much unlike development on a PC. There aren't fiddly bits in the background making things non-deterministic. The bottom line is, if I bury this bug well enough, for all practical purposes I have "fixed" it. I hate this, but I know it to be true. I don't want to use what I know to be true to move forward on this project. Burying the bug just doesn't sit right with me. But it's an option. I wouldn't be the first to do it. Far from it. Times like this call for a little Aesop Rock
Got an angel on my left shoulder, a devil on the polar Got a mug a frigid, got a mug a solar, sliiidde over The recipe's designed to plug the appetite for continuity By stitching togetherness theme congruents (beautifully) I peel back hearts and lodge greed physics in the chambers Cauterize the wound and heads like "Gimme gimme something major" Road side prophetic, ascend well (well) Enveloped in a mummy ribbon system Blistering in a wishing well BIG BANG!
I don't expect most people to understand that, but he and I communicate, even if he doesn't know it.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
I am mindful of this poem ([https://www.gnu.org/fun/jokes/last.bug.txt\](https://www.gnu.org/fun/jokes/last.bug.txt)):
Quote:
THE LAST BUG by Lou Ellen Davis "But you're out of your mind," They said with a shrug. "The customer's happy; What's one little bug?" But he was determined. The others went home. He spread out the program, Deserted, alone. The cleaning men came, The whole room was cluttered With memory-dumps, punch cards. "I'm close," he muttered. The mumbling got louder, Simple deduction, "I've got it, it's right, Just change one instruction." It still wasn't perfect, As year followed year, And strangers would comment, "Is that guy still here?" He died at the console, Of hunger and thirst. Next day he was buried, Face down, nine-edge first. And the last bug in sight, An ant passing by, Saluted his tombstone, And whispered, "Nice try."
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
I am mindful of this poem ([https://www.gnu.org/fun/jokes/last.bug.txt\](https://www.gnu.org/fun/jokes/last.bug.txt)):
Quote:
THE LAST BUG by Lou Ellen Davis "But you're out of your mind," They said with a shrug. "The customer's happy; What's one little bug?" But he was determined. The others went home. He spread out the program, Deserted, alone. The cleaning men came, The whole room was cluttered With memory-dumps, punch cards. "I'm close," he muttered. The mumbling got louder, Simple deduction, "I've got it, it's right, Just change one instruction." It still wasn't perfect, As year followed year, And strangers would comment, "Is that guy still here?" He died at the console, Of hunger and thirst. Next day he was buried, Face down, nine-edge first. And the last bug in sight, An ant passing by, Saluted his tombstone, And whispered, "Nice try."
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Haha, that reminds me of this song: Cake - The Distance - YouTube[^]
Check out my IoT graphics library here: https://honeythecodewitch/gfx
-
When I said every machine, I meant every machine I am targeting, and this all holds true for those.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
-
It does. But if that bad write doesn't actually cause an issue, and the app can be tested to work under those conditions, with that particular firmware, is it worth releasing? not for anything mission critical - it's a tool to monitor your PC's temps and usage. Sort of a philosophical question if anything.
Check out my IoT graphics library here: https://honeythecodewitch/gfx
honey the codewitch wrote:
with that particular firmware, is it worth releasing?
Perhaps in your situation (as per your other point about deterministic threads.) If you can be assured of the data flow then the error is going to be there but not be impacting anything. When I worked in C/C++ I knew the data flow was not predictable. So I could not have left that in any of those systems.
