fun( void )

When I first started learning C++ the guy who wrote the book I was read went on and on how he liked to put void in a function that took no arguments. He talked about how the editor told him that was the C way and he should drop it. So my question was why is that the C way. Well I got my answer today. I had learn some time ago the old C way of writing a function was like this

fun(arg1, arg2)
int arg1, float arg2;
{
...
return 1;
}

and the prototype would of been

int fun();

Now this was bad because the compile could not use the prototype to check the arguments. So it was changed to the way we all know and love

int fun(int arg1, float arg2)
{
...
return 1;
}

and prototype

int fun(int arg1, float arg2);

Now where does void come in. Well according "The C Programming Language" if you did a prototype for a function that takes not arguments like

int fun();

The compile will think this is the old style and stop checking the arguments so that is why they add the void.

int fun(void);

Now the compiler will keep checking the arguments. So I don't know if todays C compilers still do this or not. I know that gcc will still compile the old style of C so I am guessing it must. For C++ which will not like the old style of functions this will not matter. So it seem to keep the void in C++ is a bad idea because the problem that caused it to be used in C (being backwards compatible) is no longer a problem. So that is C/C++ story of the day.

Alternatives to XML.

In the recent article by Jeff Atwood, XML: The Angle Bracket Tax, he raises some interesting points on XML and the hiding of data inside brackets. The best resource he pointed out was a list of XML alternatives.

Brian Goetz even mentions a problem of overusing the serializing of Java Objects using XML (it is mentioned in the middle of the document).

So, in conclusion, there are alternatives out there for my configuration file needs. Could what I need be found here?

In the application, you must calculate to survive...

...He copies null-terminated strings.
And the hackers wanted in.
"I don't know who this function is, but I want him and his thread dead!"

He had one loop iteration. And his loop iteration was to copy data from one memory location to another.
Brian Kernighan...
"Listen to me! These are my null-terminated strings and I'm not going to let them overflow my buffers!"
"You have to get out of here! They're trying to kill -9 you!"

Filled with breakpoints:
"Everybody get down!"
..And more breakpoints:
"Everybody get down again!"

They didn't know where the allocated memory was...
"¡10011101 10110111!"
"Listen to me! They're trying to overflow my buffers, you have to get out of here!"

...
One man page, one post-condition. Brian Kernighan this summer is--
"NNNUUUUULLLLLLL!"
--... Little strcpy() Boy.


Pablo Francisco is one funny dude. I'll just say that much. And I will also say this: buffer overflows are no laughing matter when it comes to security issues. So yeah, these are the kinds of posts you will get from me when I have absolutely nothing beneficial to say whatsoever.

But wait, I do have something to say! I added a couple of links to pezad.com now, so we can actually use the site for linking to everything that pezad is involved in. EXIT_SUCCESS, baby!

Stess test that network

So I have been working on a robot project the last year a little. The project is to create a group of robots that play soccer with a golf ball. The hardware is almost done. The software is almost started. The part I have been working on lately is the networking.

Sense we are using Ubuntu Linux as our OS I decided to use BSD sockets to do the network programming. After I found a good guide to the sockets I was off and running. Then thanks to a networking class I am in this semester I got a good feel for what is going on behind the scenes. With that great knowledge I decided to use UDP and then to test it out and see if it worked like I hoped it would. UDP packets are best effort. I also known that a wireless network link does more then UDP and acts more like TCP. So I figured if the network link is checking to make sure the packet gets there perhaps I did not have to.

To test it I make a simple program to send a bunch of UDP packets and see how many made it. I created the program so I could set the size of the packets and set the delay between sending them and the number of packets sent. The program is still somewhat hacky, but I got it working. The result are good for the most part. If the delay between packets is more then a millisecond I get 100 to 99.9 percent of the packets making it. I the size of the packet does not matter much. As the delay between sending packets goes to zero the loss increases. So far I the highest loss was like 30%. I was able to push the link up to to 4 Mib/s by making large (1300 bytes) packet. At that limit it lost a lot, but at 2 Mib/s it was fine. I also noted that no matter how hard I push it the CPU never works hard, which is good because the robots lack CPU power.

I have to more things I want to do with the program, but the biggest is to test it over the internet. So far I have just had one hop. I want to see how the loss goes up when I don't have the full link to use and have to share.

Randomality at its finest.

So once again as far as relevance goes, I refuse to have anything to do with it. Relevance is for the irrelevant! Anywho, while perusing the ridiculously small scoped internet, I ran across some interesting things and some upsetting things. That is the nature of the beast though I suppose.
First on the list today is the topic of patents! While the fundamental idea of patents is sound, I feel the implementation should be listed on the top 10 worst ideas ever. Software patents are the worst, but not too far behind that is hardware setup that ties into software patents. While I'm not a big Microsoft fan, I've got to take their side on this thing, FullView vs Microsoft. That's right, you read correctly. Some company patented the setup of a group of cameras in a circle... Upsetting? Yes, very. Patents are the devil...end of story.
That was the super upsetting. Now time for some fun! Tomorrow is a birthday, albeit a very not so likable one. May 3 marks the 30th birthday of Spam emails! Happy birthday Spam, and you jerks who started this suck!
Speaking of spam there is a useless, but interesting site, called Worldometers. It tracks a slew of statistics related to world things. At the very top of the page you can see the number of spam emails sent for the current day! There are some more interesting things on there too.
And finally, for all you open source fiends out there, good news in the browser market. Apparently Firefox has reached almost 50% market share in some European countries with an overall market share of roughly 29% for all of Europe. That's almost a 6% increase since February! Go open source!

WHOO WHOO WHOO!!!!