"Zeiger" The Missing C Type Link

I'm just looking at an old C Compiler, the first C compiler I ever used, actually... And, I'll be honest, I didn't live with C long, I moved into C++ pretty quickly.  So much so, I never actually read the this C Compiler's Documentation, here for posterity, is an exert...

Pre-defined Data Types

----------------------

      Type        sizeof      Bits            Range

      ----        ------      ----            -----

  unsigned char      1          8             0 to 255

  char               1          8          -128 to 127

  enum               2         16        -32768 to 32767

  unsigned short     2         16             0 to 65535

  short              2         16        -32768 to 32767

  unsigned int       2         16             0 to 65535

  int                2         16        -32768 to 32767

  unsigned long      4         32             0 to 4294967295

  long               4         32   -2147483648 to 2147483647

  <pointer>          4         32

  float              4         32   (+-)3.4E-38 to (+-)3.4E+38

  double            10         80 (+-)3.3E-4932 to (+-)1.2E+4932

  long double       10         80 (+-)3.3E-4932 to (+-)1.2E+4932

  Zeiger             4         32             0 to 4294967295

I have never heard of the "Zeiger" type, it's simply an unsigned 32 bit integer, but where does that name come from?

It's a German word, meaning pointer or hand, so I can only assume it's a pointer to some memory location and the machine this compiler is for, if I recall correctly had a 4 megabyte maximum address space, plus 64K of addressable ROM.  So a Zeiger would be useful to parse over any location in both, however it's not clearly stated in the information.

Zeiger is a reserved word in this compiler, and yet it purports to be ANSI compliant... Hmmm.... Thoughts as ever in the comments below.

C++14 std::memset Not Working?

When I say not working, I do not mean the function does not work, of course it works.  What I mean is that left to it's on devices the GCC compiler can actually chose to not perform a memset in certain circumstances, you can read more detail about this in the official bug list.

So, what's going on?  Well, I have a piece of code which uses a common buffer, each function locks a mutex (std::lock_guard), fills out the buffer and then transmits over USB to target devices, crucially I then want to clear the common buffer.

The purpose of this architecture is to keep sensitive information being transmitted through the buffer present for as little time as possible (i.e. the time between filling out and transmit, ~35ms) rather than filling out, transmitting and leaving the data in the buffer; as the time between calls may be anything up to 5 seconds, plenty of time for someone to halt the program and inspect memory dispositions.

In pseudo code therefore our sequence looks something like this:

COMMON BUFFER [256]
CLEAR BUFFER

USB CALL:
    FILL  BUFFER
    USB TRANSMIT
    std::memset(BUFFER, 0, 256);

In debug this worked no problems, all my soak testing worked, I was quite happy.

Until one switches to release, whereupon the GCC compiler can opt to optimise away calls which it defines as not having any noticeable effect.

In the case of the memset call here, to the compiler, locally sees nothing inspect the BUFFER variable after the memset is performed, it therefore decides nothing is bothered the buffer is cleared or not.

Of course we know the next call to any call, or the same call, will rely on the BUFFER being empty when it enters.

There are therefore two problems, if one had this code:

USB CALL:
    std::memset(BUFFER, 0, 250);
    FILL  BUFFER
    USB TRANSMIT
    std::memset(BUFFER, 0, 256);

You would of course pass all your tests, even in release, the buffer would work as expected, you could even assume no data is being left in RAM between transmit calls; you'd be dead wrong, but you can assume anything you like really.  No, what's happening here of course is that the lead-in memset is clearing the buffer before use, but the sensitive data is left in the buffer between calls as the latter memset is still being optimised away.

The code remains vulnerable to introspective intrusion attempts.

The real solution?  Well, I've gone with:

USB CALL:
    std::memset(BUFFER, 0, 250);
    FILL  BUFFER
    USB TRANSMIT
    std::memset(BUFFER, 0, 256);
    auto l_temp(buffer[0]);
    buffer[0] = buffer[1]
    buffer[0] = l_temp;

Whatever you do to solve this, don't spend a whole day as I just have.

In conclusion, of course the call works, it's the compiler which is optimising the call away.

WD Disk DOE & Dust....

I recently ordered a new WD Blue disk, it duly arrived and had the strangest problem I've seen in many a long year, no matter what I did the disk showed as 64MB total and it lost all data upon power cycling.

I puzzled over this briefly, until I pulled the disk back out the caddy and saw it had exactly 64MB of cache, yes, no platter space was being shown, just the cache showing up as disk space.  I have never ever seen this before, cache has always been a transparent intermediary for me in production and so to suddenly have the cache being the only exposed space was odd.

However, dead on arrival hard disk, a quick RMA and a new one winged its way into my hands, they actually gave me a slight upgrade as I got a WD Black by return of post.

Tonight I planned an hour to fit the new disk and add it to my workstation.... This machine has no cable management, and its a nightmare to add drives, there are six built in 3.5" bays but they have a set latch and screw mechanism, which forces you to fit the drives to that the power connectors are actually straining the distant power plugs. (I do plan to buy a pair of SATA power extenders on pay day).

What struck me as a massive problem however, is the amount of dust inside there.  Clearly, since fitting the 1080 GTX I've had something change or fail or open as there are copious amounts of dust in there.

Now my work area is not optimum for a workstation, I have a full tower case, so it has to go under the desk and the floor is carpeted.  Now this had been mitigated by the Coolmaster Cosmos 1000 case having lifting rails, taking the whole thing 1.25" off of the floor level, and two ground level filters, as well as a rear and front filter set.

But clearly things have not gone well, as just dust dust dust.

My original plan for the start of the year was to re-case the server, then re-case this PC as a server as well, retire one of the aging DELL 2950's for this machine itself, and put myself a new workstation together for my 40th.

Trouble is?... I'm skint, like proper skint, so I can't afford the workstation I was planning on...

And now I need to sort out this machine... I smell another re-casing task a head... Hmm, which case?  I'm thinking about the Corsair Obsidian range... Anyone have any other suggestions for a full height tower?... 1 x 5.25" at least 6 x 3.5" internal mount points and at least 2 x 2.5" mount points internally.  Front Panel USB would be a boon.

Dust seems to be my enemy.

Windows : Com File Effect

I'll never claim to know everything about Linux nor Windows, I know a lot more about the former than the latter, mainly as the Windows is a closed source product.  As such it doesn't get my attention as much, unless something is going wrong.... Today I have found an effect I can't explain (at least not easily) in windows, clearly it's some sort of reserved file name or type effect.... Maybe you can explain this to me.

So, open any folder, right click and go to create a new text file...

Once you have the file...

Change the name to "COM" and a port number, so "COM1" in my case.... It can be any COM port name, even if you don't have that port installed or active on your machine....

Once you complete the name, or change focus of the text entry (by say taking a screen shot - not actually committing the new file to disk) you get this strange message...

"The Specified device name is invalid"....

What device?  I'm trying to create a filename.  I was immediately a little puzzled, I've used Windows since Windows 2.0  I've never ran into this issue.

Googling around I find a chap on social.technet.microsoft.com saying not to use a whole plethora of names for files or folder as they're reserved, I have never heard of this.

The official Microsoft advice likewise says not to use these values, and it kindled a memory in me from programming in DOS 6 back in the mid 90's, one would in Pascal, you could "println(PRN, 'some message');" and see the message print out on the printer.

I find it amazingly odd that these files are still reserved in 2018, they're proper nouns, they're things you may want to name files, and they have a FULL Path, which makes them very distinct than the COM port device.  Its odd, trust me.

But the oddest thing is, what does Windows do, what is the piece of code picked up and made to run that message box upon creation of the file?  And I've got to wonder how exploitable that maybe in local malware to open lots of message boxes and annoy the user.

Menstruation is Normal, in 1989 everyone knew, yet not today?

I'm going to come back to this again... In 1989, in a dusty second floor science room at what was Top Valley Comprehensive School I sat down with my then classmates and we had our first sex-education lesson.  Mr Simpson the (unfortunately) body odour riddled and forever exacerbated physics teacher had to teach us young folk about masturbation and menstruation, and ultimately where babies arrive from.

Not one picture of a stalk was had, not one allusion to fact, not one sugar coating, we had a video of (admittedly a cartoon of) a boy holding his penis and the narrator saying it's okay for this to feel good.  We had a young lady (again a cartoon) fondle herself and we were again told this was normal, we were shown putting condoms onto bananas to everyone's mirth as we'd mostly all seen and even used condoms before... This is Top Valley Estate bruv.

And the last part of this talk was about periods.  We were all told all girls start to have periods, it is normal, we were taught about pads, tampons and even moon cups.  We were told, point blank, about how much menstrual blood a girl should expect; and I remember a fair few of my female class mates blankly stating they would say that a vastly conservative estimate.

THIS IS 1989...

Let me make that clear, nineteen eighty-nine.

So, why the hell are articles like this appearing in 2018?

http://www.bbc.co.uk/news/newsbeat-42871791

I am utterly baffled and confused by this... Was my school vastly a head of its time?  I don't think we were, we were a daggy comprehensive intended to turn our plasterers, car mechanics and dust-bin men.  It was not an Engineering specialist (read that as "turning out car mechanics") as it is now as an rebuilt academy.

What on Earth has happened in this time?

What has the Department of Education been up to?  How can I go back and check the 1989 Personal and Social education syllabus I was enrolled upon against today's?  Because I remember this episode.

I remember it as it made me vaguely uncomfortable, a period was something my mother had, with her big box of giant canoe like panty liners.  The pretty girls in class with me, they didn't have them, "old women" had them.  It was a genuine surprise, and it is one of the few times during my secondary education where I remember being taught something.

So why are kids today not being taught the same thing?  Again, why this retrograde step?

Healthier Lunch #1

I've been trying to eat more healthily at my desk... Here's the "healthier" option....

Oat So Simple?  More like Owt So Wall-Paper Paste.....

Home Server - New Case (Coolmaster N300)

The new home server build starts with the case, I've elected to go with my wallet, and this means the cheapests ATX case with the mode drive bays...

The Coolmaster N300 comes in at just over £38 and sports an impressive 8 internal 3.5" drives.

Intel Home Server CPU

You're all aware (I hope) of my stack of servers under the desk, however, the main server I use is actually a re-purposed desktop - it's the G33 chipset Socket 775 to Socket 771 running a Xeon E5420...

And I have my plan forming to re-case my main workstation, however, I wondered... As I'm currently very exposed with data not replicated across drives on my little server and the machine being quite high power, whether I might not do better in the short term of recasing both... AND changing the server to an always on box.

This way, I could build a machine around a dedicated new board and chip... I started out with the AMD APU's the 2580 and some others, up to a quad core, and as fabulous as they look on cost they didn't float my boat.

I don't need a lot of number crunching power on the server, so what was my concern?  Well, I'm an Intel guy... Always have been, and think I always will be.  Obviously I started with MOS processors, then moved into the world of Motorolla, but since 1994 I've steadfastly bought and used Intel.

Why? Well, I remember the original AMD offerings, they were copies, and hard to find in the UK market without knocking the quality of other items in your build, so I stuck with off the shelf Intels.

I then build my own Pentium II and III computers, I also found use for Celerons - I've never had anything against them - I had a Pentium IV Prescott when they were literally brand new, then I've had the Core i7 950, plus all the Xeon servers and modding fun.

At work I've always been supplied Intel too...

What options does the market offer in the Intel world?.... Well I spotted the dual core, dual thread Celeron G9300.... Which looks just the ticket for me, it's pretty low power (53W compared to the Xeon E5420 at 80W), it can address more RAM, so giving me expansion options and it had decent reviews.  The trick is to not expect a lot from it, and to actually put it to a good use.  If that use is as an SSH point into my network, a git server, NFS host and squid box, then that might work quite well.

I've therefore drafted a build, you can see it here.... 

If nothing else that case, might be a perfect buy, to get the ball rolling, and guess what!... Tomorrow is pay day.