02 May, 2011, Vigud wrote in the 81st comment:
Votes: 0
Runter said:
Yeah, I agree with Vigud. That's good C code, but this is best C code.
while(1)
;


I've came across this piece of code recently:
#include <stdio.h>
#include <sys/vfs.h>

void main() {
struct statfs fs;
statfs( "./", &fs );
printf( "Free: %lu MB\n", fs.f_bavail * fs.f_bsize / ( 1024 * 1024 ) );
}
It's wrong. Try to guess why and how to fix it.
02 May, 2011, JohnnyStarr wrote in the 82nd comment:
Votes: 0
I'm sure I'll get crap for this, but I really love the .Net framework.
I prefer VB.Net over C#.

Strings are very easy to manipulate, and VB.net has a ton of features similar to
a dynamic typed language, but structured as a strictly typed language.

If you decide to go live with a *nix box, you can always use MONO.
02 May, 2011, David Haley wrote in the 83rd comment:
Votes: 0
Probably has to do with overflow, rounding problems, something like that. (after a 3-second read)
03 May, 2011, Tyche wrote in the 84th comment:
Votes: 0
Vigud said:
It's wrong. Try to guess why and how to fix it.


Fixed it. :-)
#include <stdio.h>
#include <windows.h>

void main() {
unsigned long long fs;
ULARGE_INTEGER fb;
GetDiskFreeSpaceEx( NULL, &fb, NULL, NULL);
fs = fb.QuadPart;
printf( "Free: %lld MB\n", fs / (1024 * 1024) );
}


PS. Should you be using statvfs() instead? statfs() appears to be deprecated, and I think statvfs struct has 64-bit fields.
03 May, 2011, Kaz wrote in the 85th comment:
Votes: 0
Vigud said:
It's wrong. Try to guess why and how to fix it.


Obviously, it's because main should return int. :devil:
03 May, 2011, Vigud wrote in the 86th comment:
Votes: 0
I believe that the code you write and what it's meant to do are two very different things. The latter is a plan, an algorithm, or any other kind of a set of instructions. The former is all about how well you express your thoughts and translate them into a language that has some rules you shouldn't break if you want your code to be good. So both can be evaluated, but each of them should be evaluated separately. If you describe a bad plan correctly and thoroughly, it doesn't mean that the description is bad. Correctly written code isn't bad, even if it implements piss-poor quality algorithm.

So the original piece of code, the one that keeps picking random numbers until it finds one that meets criteria, I guess is an algorithm good enough to be used in a MUD (possibly not the best one, though, therefore I can understand the dislike for the method) but I'm convinced it's fairly correctly written (expressed in C), which I call good code.

There was another example of bad code that was discussed here on Mudbytes. The one where someone was concerned by warnings their compiler was spitting out; the warnings were telling them that there's an overflow in assigning value of int to a variable of type char. We all agreed that something was wrong, because int of value 2^9 is interpreted as TRUE, but it doesn't fit into 8 bits, so is truncated to 0, which is interpreted as FALSE, which resulted in the function lying about whether some flag was set to a character or not. The way all that stuff worked wasn't that bad at all, it was just an error in the code; the code was bad, not necessarily the method.

And there's this example of bad code I posted yesterday. I was having an annoying problem with some application I use – it was telling me I had around 300 MB of free space, while I had 265 GB. The problem, as well spotted by David Haley, was that the number of bytes of free disk space didn't fit into 32 bits (which is the size of int on my system) so it was getting truncated to a silly low number. That was, in my opinion, bad code and I posted it here as an excuse to explain my previous messages in this topic where I gave my opinions on whether some piece of code was bad or not.

The way I would fix the example is based on the source code of GNU df utility:
printf( "Free: %lu MB\n", (unsigned long) (fs.f_bavail * (fs.f_bsize / 1048576.0)));

Quote
PS. Should you be using statvfs() instead? statfs() appears to be deprecated, and I think statvfs struct has 64-bit fields.
I'd say that in this context it's not that relevant. Generally, yes, statvfs() is the POSIX standard way of doing that, so you should be using it instead of statfs() if you want to improve the portability of your code along various unix-like operating systems. However, statfs() itself is portable between 32-bit Linux and 64-bit Linux (and a few other systems, I believe), since the glibc statfs() and fstatfs() wrapper functions transparently deal with the kernel differences.

Quote
Obviously, it's because main should return int.
It's true that the C standard requires main() to return an int. In addition, it should either take no parameters (int main(void)) or take two parameters: int and char **. But that wasn't the point :)
80.0/86