OSDev.org

Posted: **Wed Jul 09, 2003 3:00 pm**

I'm testing my C++-skills so far by making a text editor in as less lines as possible. It compiles up 'till now, but the program itself keeps on crashing (the light of the HD flickers for about half a minute, the user can't do anything and the program crashes afterwards)

This's my code:

Code: Select all

#include <iostream.h>
#include <stdlib.h>
#include <string.h>
#include <stdio.h>

int main()
{
char text [999999999];
char answer[2];
char filename[13];

scanf("%c", &text);
fflush(stdin);
printf("Save? Y/N");
scanf("%c", &answer);
if (answer == "Y") {
  printf("Yes");
}
else {
  printf("No");
}
system("PAUSE");

return 0;
}

I think the problem's somewhere in the char text [999999999];-part, but I don't know how to fix it.
Thanks for the help.

-Kon-Tiki-

Posted: **Wed Jul 09, 2003 3:19 pm**

You're trying to reserve nearly 954MB for the variable 'text'. Why do that, if you only need one character?

Anyway, your scanf line is wrong. You've told it that you've given a pointer to a char (by using "%c"), whereas what you've given it is a pointer to a char*.

In fact, the scanf line doesn't even do what you want. It's trying to read a single character. I assume you want to read a whole line.

So:
-- reserve a *lot* less space for your text variable. If you don't want to place a limit on the amount of text the user can type, use malloc/realloc
-- use fgets instead of scanf to read an entire line

Posted: **Thu Jul 10, 2003 10:27 am**

I guess this is a mistake when you copied the code but the line:-
char *text [999999999];

Looks wrong. Why is there a space in between the *text and [999999999];

Posted: **Thu Jul 10, 2003 11:35 am**

A space? Dunno if that matters, and what does that * mean?

Tim: looked for the use of malloc and realloc, but weirdly enough, I only find technical information, not how to use them :-\

Thanks anyway, I'll just have to look further.

-Kon-Tiki-

Posted: **Thu Jul 10, 2003 12:27 pm**

Code: Select all

char *text;
/* Allocate 10 bytes and point text to the start of the block */
text = malloc(10);
strcpy(text, "Hello!");

/* Make text point to a 20 byte block. realloc might move the block, so we have to assign the return value back to the text variable. */
text = realloc(text, 20);

/* Prints "Hello!" -- text still contains the same data, even if it's moved */
printf("%s\n", text);

/* Append to text -- we know that it's big enough -- 20 bytes is longer than the length of "Hello!" + " World!" + <terminating nul character> */
strcat(text, " World!");

/* Prints "Hello! World!" */
printf("%s\n", text);

/* Remember to free the block when we've finished with it, thereby releasing memory back to the OS for re-use */
free(text);

Did you get yourself a book on C or C++? The book "The C Programming Language" by Kernighan and Ritchie explains all of this, and more.

Posted: **Thu Jul 10, 2003 7:30 pm**

The main problem, aside from the excessively large buffer and the incorrect scanf() call, is that it offers no real editing at all, just input. As it is, this will (once the scanf() call is fixed) read in exactly what he user types in, no more and no less, with no actual editing. It is effectively equivalent to using "[tt]cat >filename[/tt]" to capture text from the console. Any non-printing characters (e.g., backspace) will most likely go right into the text stream unprocessed, and end up in the final file. True, 'cooked' mode input under Unix will process some basic editing commands by default, but relying on it is probably a Bad Idea.

Even in a minimal editor, you'll probably want to use Raw Mode (unbuffered) input and interpret the text stream directly. Of course, that also means doing your own screen handling, but again, relying on the system buffered input to display things correctly is unwise anyway.

While it is far more than you probably want, given the goal of writing a minimal line editor, you might want to find Illumination fnord through the classic text on the subject, Finseth's The Craft of Text Editing. It discusses all of the major considerations in writing a text editor - text input, command processing, screen handling, buffer management, text transformations - in considerable detail. Well worth reading just for it's general programming insights.

Posted: **Mon Jul 14, 2003 3:34 pm**

While the rest of your post is correct, Tim, you made one error in this part:

Tim Robinson wrote:Anyway, your scanf line is wrong. You've told it that you've given a pointer to a char (by using "%c"), whereas what you've given it is a pointer to a char*.

This is a classic misunderstanding, and rather subtle point: the value of an unsubscripted array variable is the first item if the array itself, not a pointer to the array. In assembly langauge terms, the array identifier is a label for the whole array, and the subscripts are offsets to the components of the data structure. Or, to put it another way: given the declarations

Code: Select all

char array[10];
char *ptr - &array;

then

[tt](array == array[0])[/tt] is true, and
[tt](ptr == array)[/tt] is false. This is also why array identifiers are constants: they don't point to the memory locations of the array, they are the memory locations of the array.

HTH.

Posted: **Mon Jul 14, 2003 3:58 pm**

A fair point. In fact, since the name of an array represents the address of the start of the array, having a pointer to the array's name would be impossible -- it would be like taking the address of a constant.

Code like this would still be meaningless if what I said were true:

Code: Select all

char a[10];
char **p;
p = &a;
*p = "Hello";

This is similar to the use of function pointers; function_ptr and *function_ptr are the same thing, since dereferencing a function pointer is meaningless.

OSDev.org

Small text editor

Small text editor

Re:Small text editor

Re:Small text editor

Re:Small text editor

Re:Small text editor

Re:Small text editor

C arrays vs C pointers (was Re:Small text editor)

Re:Small text editor