Stuff For Gurus
All users are urged to read the DISCLAIMER page on this blog before proceeding on this page.
A simple demonstration of how the void pointer can be used to add advanced functionality to the C Programming Language. Pay particular attention to the Object-oriented-type operations.
We have learned that pointers, in C, have a lot in common with arrays. What the 'common' text hardly mention, is the advance method of allocating them, in a way that they can be manipulated in a more advanced manner.
A C compiler (comforming with the ANSI C standards) should, under normal operating conditions, complain about the declaration of an array without the statement of an initial size or the initialization of it... But there is a little tricky/(buggy) way of achieving such a feat (even with the -ansi switch turned on).
And if you are familiar with the concept of stack overflow, buffer overflow or stack smashing, you can always 'follow the white rabbit'.
Ever wanted to enter integers, and only integers, and never wanted to make a mistake by entering any other character? Then there is the overly annoying fflush(stdin).
In some IDEs' include (header) files, conio.h contains predefined color values for console coloring. The said header file may even have a function that handles the coloring when these predefined values are passed to it. The main drawback here is that this functionality is normally limited to a specific platform/operating system or IDE.
But what if you want to write portable (cross-platform) console apps, for any specific valid reason, that require console coloring for easier user interface? Instead of having to 'bitwise' undefined color values for each instance that a specific color needs to be applied, it is best to have a greater number of predefined variants at hand... plus examples of how the basic derivatives can be mixed to yield desired results.
NOTE: The function, defined in the wincon.h (windows.h) header file that is natively responsible for general console 'text' coloring on Windows is SetConsoleTextAttribute. Complete console coloring will require the CONSOLE_SCREEN_BUFFER_INFO structure and affiliated functions.
There is actually a 'perfect' way to compare strings without even having to worry about (m)any insecurities. And what if the strings you are comparing is a password?
There is no doubt that a majority of system compromissions are owed to time vulnerabilities. It is bad enough that your hardware have hardware built on them that increase the chances. With that reality in mind, what can you do to diminish any such loophole any chance you get? Arguably, any such work will have to be done, overwhelmingly, at the software level.
For that sole reason, what if you could have all your code in one place, with very limited scope, hence, very limited chances of any such flaws?
There are often times when a file, that is critical to system operations, MUST exist in the location specified. But what if there is a simple alteration to such a file, such as the changing of its attributes, that can render it inaccessible to critical system processes/operations?
Log files on a mission-critical server is a perfect example of one such type of file. A log file is needed to diagnose any kind of issues: security, hardware/software, customer usage, etc. The greatest effort should be made to make sure such a file always exists (in the desired location) and is always accessible.
HTML 5 + CSS3
Being that in HTML 5 has rendered the <center> element and the 'align' attribute deprecated (in favour of CSS), now is the time to find foolproof ways of achieving those overly annoying tasks from the past life of web development.
How about specifying fixed dimensions for your web site and, being that it will seem out of place (hugging up on the top left hand corner of your browser), the next fundamental goal you would like to achieve is to get it exactly in the middle of whatever browser, on whatever platform/operating system, even with the browser window resized.
Considering the stated opening fact, CSS is expected to be the workhorse for this exciting coding adventure.
NOTE: After learning in high school math class that 'variety is the spice of life', which epitomizes the fundamental Einsteinian concept (regarding madness):
Without further ado, here goes...
Undoubtedly, in the age of HTML 5 and CSS3 even, the skilful alert dev, with no more than a pair of well-made dev 'pruning shears', so to speak .oO(and a lightweight text editor), can pull of this trick spectacularly well. "And the benefit of the end product?", you may ask. How about lesser CPU overhead for starters? What about your multimedia-playing browser hogging a bit less RAM? Etc, if you know what I mean.
NOTE: There is no doubt that any form of menu-driven site will, more than likely, have to employ Dynamic HTML (DHTML) so the above effort will definitely make more resources available for this implementation.
There are those fancy shiny things on a website that can cause an annoyance to visitors, and then there are those aptly placed well-fashioned elements, containing info that the site owners/dev might consider most relevant to its users: deadlines for instance.
In the case of the latter scenario, how about a glowing div that catches the eye of anyone upon site entry?
What would make the language more interesting though is (epitomizing DHTML in its true sense), the ability to create variables with variable names and: var "foo" + "bar" = null; is not possible.
var "foo" + "bar" = null;
i. You want to store and manipulate separate values with similar patterns (which could be done using arrays), but:
ii. All of the values will not always be used (so arrays would waste memory resources, plus a space used by one value could always be freed for another), and definitely not in the same order all the time, and:
iii. You always want to access them as they are stored regardless of which one is stored first, so:
iv. It sounds as if indexing the variables (currently being used), with some sort of naming convention, is a good idea, therefore:
v. The 'Object' object comes to mind; finally:
vi. The underlying concept here, is the ability to (not always) store and/or (not always) manipulate, some/any/all of the content of similar objects in a particular scope, using the same limited, unrecurring code.
How about an unflinchingly rigorous, lo-chol console menu, that delivers as expected, and does nothing else? (Not even crashing.)
kryptos => secret, graphos => writing
In WWII, the British, having obtained an Enigma cipher machine that the Germans used to encrypt their cables, were able to analyze it and deciphered the Nazi's secret codes, which resulted in a significantly shorter war and, eventually, a devastatingly lesser loss of lives and infrastructure (oxymoron intended).
In a time when modern computers almost never existed, one can extrapolate that, had Hitler had the power of the least significant modern microprocessor, the result of the war would be remarkably different, and, albeit the Allied Forces winning, their population would have been reduced to shards. In such a case, one can even hypothesize the Allied forces employing women and children to gain the final advantage.
The resounding theme, in the British's success in decrypting the Nazi's encrypted communication, is reverse engineering.
...and what if us all have an idea of how the not-so-simplest cryptography works.
Sooner or later a programmer will have to accept the challenge, as is evident from the website with the obvious domain name.
While these snippets are posted on the said website, I thought it would be a good idea to put my own work on my blog.
NOTE: 1) Not for kids. 2) Phr0z3n.Dev prefers Whiskey or Vodka. 3) If you have to, drink responsibly and securely.
Leave a comment...