Thread: SDL_textinput and strcat crah

I was following this example (Tutorials/TextInput - SDL Wiki') but strcat text_input crashes the program for some reason, any ideas?

Code:

    char *text_input;

    ...
            case SDL_TEXTINPUT: {
               strcat(text_input, event.text.text);
            } break;

In order to strcat to text_input it must be pointing to some allocated memory. It also must contain a valid (possibly zero-length) C-style (i.e., zero-terminated) string.

Code:

text_input = malloc(200);
*text_input = 0;  // set first byte to '\0'

You would also need to keep track of how much text has been stored in it so far and realloc as necessary, and eventually free the memory. Usually you would learn this kind of thing with console programs and then move on to SDL.

The example from your link is obviously incomplete. Note the /* ... */. It's also noteworthy that the variables are declared extern, usually indicating that they are defined in another source/object file.

It seems to be the double-pointers that are confusing you, but I don't understand why the textures are double pointers in the first place. They should probably be single pointers. Maybe you're confused by the double-pointer that is used in the load_texture function, but it uses a double pointer there so that it can modify the pointer in the caller.

You could even get rid of the double-pointer in load_texture by passing back a pointer instead of passing in a double-pointer. This seems more natural to me:

Code:

SDL_Texture *load_texture(const char *name) {
    SDL_Texture *t;
    ...
    return t;
}

SDL_Texture *texture_gray_btn = load_texture("textures/btn_gray_active.bmp");

BTW,
Calling your button "struct_button" eliminates the advantage of the typedef since without the typedef it would be called "struct button" (exactly the same but without the underscore). Structs are usually named with the first letter of each word in uppercase, so Button would be a good name:

Code:

typedef struct Button {
    ...
} Button; // it's okay for this to be the same as the struct tag.

Also, you don't need to write "\0". A plain old "" will do since a string literal adds a zero-byte at the end automatically.

Thanks for the pointers.

The reasoning behind double pointers, is that i want to be able to free the texture idependantly of the Button or if multiple Buttons share the same texture, but as you say they are pointers. maybe... it would already work like that.

Originally Posted by Tiago Redaelli

The reasoning behind double pointers, is that i want to be able to free the texture idependantly of the Button or if multiple Buttons share the same texture.

I can't see how double-pointers would help with that. Try the single pointers and see how it goes.