I’ve got problems using strings from within a SDL program. Whenever and
wherever I use sprintf(scorestring, “%d”, score); I get a Segmention
fault
with SDL-Parachute (whatever this is), although there aren’t any errors
while compiling. I don’t understand this. :-/
Do you know how to fix this? Perhaps there’s another function converting
int to *char.
cu
G?nther–
±------------------------------+
| .~. |
| / V \ |
| /( )\ |
±------------^^-^^-------------+
| @gnoack_at_guentherno |
| http://www.guenthernoack.de |
±------------------------------+
| F?R BANNERTAUSCH iMMER BEREiT |
±------------------------------+
I’ve got problems using strings from within a SDL program. Whenever and
wherever I use sprintf(scorestring, “%d”, score); I get a Segmention
fault
with SDL-Parachute (whatever this is), although there aren’t any errors
while compiling. I don’t understand this. :-/
Do you know how to fix this? Perhaps there’s another function converting
int to *char.
This isn’t an SDL problem. What’re your declarations for 'scorestring’
and ‘score’?
I imagine that perhaps “scorestring” is a “char *” but which was never
assigned to any memory (eg, with “malloc()”), so when you try to 'sprintf’
into it, your program tries to write into some invalid memory.
Hence, segfault.
You’re lucky you’re not on some lamer OS, where that could corrupt your
system entirely.
I imagine that perhaps “scorestring” is a “char *” but which was never
assigned to any memory (eg, with “malloc()”), so when you try to 'sprintf’
into it, your program tries to write into some invalid memory.
Thanks! You’re right…
What I didn’t know was that I had got to re-malloc the string everytime
I
use sprintf (It has to be updated every time the score increass…)
cu
G?nther–
±------------------------------+
| .~. |
| / V \ |
| /( )\ |
±------------^^-^^-------------+
| @gnoack_at_guentherno |
| http://www.guenthernoack.de |
±------------------------------+
| F?R BANNERTAUSCH iMMER BEREiT |
±------------------------------+
I imagine that perhaps “scorestring” is a “char *” but which was never
assigned to any memory (eg, with “malloc()”), so when you try to 'sprintf’
into it, your program tries to write into some invalid memory.
Thanks! You’re right…
What I didn’t know was that I had got to re-malloc the string everytime
I
use sprintf (It has to be updated every time the score increass…)
I imagine that perhaps “scorestring” is a “char *” but which was never
assigned to any memory (eg, with “malloc()”), so when you try to 'sprintf’
into it, your program tries to write into some invalid memory.
Thanks! You’re right…
What I didn’t know was that I had got to re-malloc the string everytime
I
use sprintf (It has to be updated every time the score increass…)
This sounds wrong, somehow…
Why not just use a normal char array that’s big enough to fit the
largest number (plus a “NUL” at the end) and use that?
If you’re worried, you can always use “snprintf()” (but, d’oh, that’s
not available in all environments! Stupid C designers!)
I imagine that perhaps “scorestring” is a “char *” but which was never
assigned to any memory (eg, with “malloc()”), so when you try to 'sprintf’
into it, your program tries to write into some invalid memory.
Thanks! You’re right…
What I didn’t know was that I had got to re-malloc the string everytime
I
use sprintf (It has to be updated every time the score increass…)
Uhm, why…?
Normally, you’d just allocate enough space for the largest string you expect
(possibly as uninitialized, static arrays to avoid dealing with dynamic
allocation alltogether), and then reuse the buffer. Memory allocation isn’t
free, and it’s not deterministic (ie it may cause occasional stalls due to
swapping to get more memory when the brk limit is hit).
And, DON’T use sprintf()!!!
Ok, in this case it’s probably not a system security hazzard, but many
experienced programmers recommend that the “n versions” (snprintf(), strncpy()
etc) should be used instead, at all times. This eliminates the risk of
corrupting memory after buffers and similar nasty bugs. Memory corruption and
pointer bugs are the hardest ones to find (if you observe them at all before
the users do!), so make it a habit to make sure you don’t get them in the
first place, whenever you can.
//David
…- M u C o S -------------------------. .- David Olofson --------.
| A Free/Open Source | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
| for | | Open Source Advocate |
| Professional and Consumer | | Singer |
| Multimedia | | Songwriter | -----> http://www.linuxdj.com/mucos -'—> david at linuxdj.com -’
If you’re worried, you can always use “snprintf()” (but, d’oh, that’s
not available in all environments! Stupid C designers!)
And people blame C for being a bug prone, low level language!?
IMHO, C doesn’t really have any serious problems - APIs do. (I one wrote an OO
GUI toolkit in 68k asm, and it lowered the bug frequence very significantly!
You don’t need complex, abstract language constructs to avoid memory thrashing
bugs - the most common problems are obviously found elsewhere.)
//David
…- M u C o S -------------------------. .- David Olofson --------.
| A Free/Open Source | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
| for | | Open Source Advocate |
| Professional and Consumer | | Singer |
| Multimedia | | Songwriter | -----> http://www.linuxdj.com/mucos -'—> david at linuxdj.com -’
