Page 1 of 1

several questions

Posted: Sat Dec 03, 2011 9:14 am
by c0d3Man
Im not a very experienced programmer, I haven't made many applications (basically cause I'm idea-less so if anyone has any ideas for something to help with experience and the like please let me know), and I know the C++(at least the basics I think, if someone knows of a website that I could use to make sure I know the all the basics and to increase my knowledge then it would be great if that could be put into the comments also), I would love to get into OS dev but to avoid looking like an idiot I'm gonna hold out on trying any serious stuff that is related to it. also, I was working on Bran's kernel development tutorial, and I mainly was doing it to see how far I got before I couldn't complete the asked, anyways, I got to the part that had to do with writing main.c (I do generally know the very basics of C also), I was curious as to your all opinions on some of the functions I wrote in comparison to the "solutions" he provided. any tips or letting me know of anything I did wrong or could have done better would be greatly appreciated.

Mine

Code: Select all

/* You will need to code these up yourself!  */
unsigned char *memcpy(unsigned char *dest, const unsigned char *src, int count)
{
    /* Add code here to copy 'count' bytes of data from 'src' to
    *  'dest', finally return 'dest' */
	int x;
	x=0;
	while(x<count){
		dest[x]=src[x];
		x++;
	}
	return dest;
}

int strlen(const char *str)
{
    /* This loops through character array 'str', returning how
    *  many characters it needs to check before it finds a 0.
    *  In simple words, it returns the length in bytes of a string */
	
	int count,x;
	count=0;
	x=0;
	while(x!=-1){
		if(str[x]!=0){
			count++;
		}
		else if(str[x]!=0){
			x=-1;
		}
		x++;
	}
	return count;
}
Bran's solutions

Code: Select all

void *memcpy(void *dest, const void *src, size_t count)
{

    const char *sp = (const char *)src;

    char *dp = (char *)dest;

    for(; count != 0; count--) *dp++ = *sp++;

    return dest;

}

size_t strlen(const char *str)
{
    size_t retval;
    for(retval = 0; *str != '\0'; str++) retval++;
    return retval;
}

Re: several questions

Posted: Sat Dec 03, 2011 11:11 am
by neon
Hello,

Neither of those solutions are really good (yours and the ones provided in the tutorial). Your solutions are unnecessarily complicated however. This does not mean your routines are "wrong", just that they can be written better.

What can be written better in your code is pretty obvious I think...

1. Why have int x; x=0; on separate lines? Why not just do int x=0; ?
2. strlen is way more complicated then it needs to be.
3. memcpy should use void* as par C standard.
4. strlen should return size_t as par C standard.

If you do not want to follow the C standard when defining routines, I advise naming them something else to avoid possible confusion later on.

Re: several questions

Posted: Sat Dec 03, 2011 11:18 am
by c0d3Man
I do thank you for your response, but could you possibly clarify what you mean in 3 and 4 and the statement thereafter?
3. memcpy should use void* as par C standard.
4. strlen should return size_t as par C standard.

If you do not want to follow the C standard when defining routines, I advise naming them something else to avoid possible confusion later on.
what is void* and size_t?

Re: several questions

Posted: Sat Dec 03, 2011 11:35 am
by neon
Hello,
  • void* is a pointer to raw data. Its a basic data type in C and C++. Because its raw data, you need to cast it to a type in order to use it. If you look at Bran's code, you can see how he casts for an example.
  • size_t is defined in <stddef.h>. It is typically typedef'd as an unsigned int. It is used to represent the size of an object. Because you need to develop your own libraries, you need to define your own stddef.h

Re: several questions

Posted: Sat Dec 03, 2011 12:05 pm
by c0d3Man
ok, many thanks, I'll have to learn more about casts :)

Re: several questions

Posted: Sat Dec 03, 2011 6:30 pm
by Combuster
neon wrote:size_t is defined in <stddef.h>. It is typically typedef'd as an unsigned int. It is used to represent the size of an object. Because you need to develop your own libraries, you need to define your own stddef.h[/list]
Actually, using unsigned long as size_t is correct in far more cases, including all the ones you will encounter as a starting developer. int breaks on 64-bit environments.

Re: several questions

Posted: Sat Dec 03, 2011 7:38 pm
by Brynet-Inc
Combuster wrote:
neon wrote:size_t is defined in <stddef.h>. It is typically typedef'd as an unsigned int. It is used to represent the size of an object. Because you need to develop your own libraries, you need to define your own stddef.h[/list]
Actually, using unsigned long as size_t is correct in far more cases, including all the ones you will encounter as a starting developer. int breaks on 64-bit environments.
What? long breaks on 64-bit environments, int is reliably 32-bit in ILP32/LP64 and even LLP64. Which are the most common programming models.

DOS/Minix2 were typically LP32 (..rather I16LP32), I can't think of any other examples.

Re: several questions

Posted: Sat Dec 03, 2011 7:39 pm
by Owen
Combuster wrote:including all the ones you will encounter as a starting developer
...excepting 64-bit Windows

Re: several questions

Posted: Sat Dec 03, 2011 7:43 pm
by Brynet-Inc
I think I misunderstood Combuster, and indeed, size_t should be declared unsigned long.

Re: several questions

Posted: Sat Dec 03, 2011 8:41 pm
by Love4Boobies
I just hope the OP understood what everyone meant; I'm not a big fan of "that will work for now." It's not particularly difficult to understand what the purpose of size_t/ptrdiff_t is.

I would recommend that, before starting OSdev, the OP read the following books (note that the erratas can be found on their respective websites):
and get a copy of the C standard (or at least the latest publicly available draft). Note that C1X was finalized and it will probably be published by ISO/IEC early next year; much earlier than POSIX:2008 TC1.

Re: several questions

Posted: Sat Dec 03, 2011 9:25 pm
by c0d3Man
Actually, I would prefer to use C++ rather than C if I can get away with it. I still need to make sure I understand everything about C++ before I actually tackle OSDev in a serious manner...

Re: several questions

Posted: Sat Dec 03, 2011 9:54 pm
by Love4Boobies
This is going to sound weird, but C++ is one of the few things you don't need to understand completely. You'll sometimes hear people complain about it being overly complex. But the truth is that it was designed in such a way that people need to understand the big picture and then settle only on the subsets they need.

Re: several questions

Posted: Sat Dec 03, 2011 11:41 pm
by Tosi
If you're going to do OSdev, don't use C++ if it's your first time. It is a lot easier to get a bare-bones C kernel running than a bare-bones C++ kernel, unless you don't use certain C++ features like exceptions and memory allocation. If you don't know C, learn it before attempting OS dev. You should also learn the assembly language for all of the processors you wish to target.
Second, if you are not an experienced programmer, OS dev is not for you. Read the Getting started section on required knowledge. The first 5 bullets and the last one are the most important; UNIX experience is extremely useful, but not necessary since there are tools you can use on other systems to develop an OS. You should of course know your toolchain, but if you are experienced you might want to try different toolchains and so could probably figure it out from the manuals. Knowledge of executable formats is necessary, but not right from the get go. For a beginner, I would recommend ELF or a.out. PE is more complicated, but you may be more familiar with it. Rolling your own executable format is like rolling your own anything: you must know what you are doing and plan as much as possible before writing a single line of code.

Re: several questions

Posted: Sun Dec 04, 2011 6:57 am
by Combuster
Owen wrote:...excepting 64-bit Windows
Beginners should not be using 64-bit MSVC for OS development :wink:

Re: several questions

Posted: Sun Dec 04, 2011 5:22 pm
by c0d3Man
Yeah, I'm not that experienced, I plan on trying to write some programs to better acquaint myself with C++, I did originally learn C before I learned C++, but like I said, I don't have any ideas for some programs, I do like to do video game design but I have yet to figure out how to get real time input, I think I've almost figured out a way to do it but not yet. Also, I don't know how to do memory allocation in C++, I also don't know how to use exceptions in C++( it's possible that I do know how to use either of the last two, but if I do, I don't realize it), I recently got the manual for the x86 processor family, and I also am going to try and learn to compile from the command line, right now I'm using the a.out format for my kernel but that's just because of the tutorial I was messing with. I don't need to understand it completely as I am trying to learn things that are could be very useful.