Nonconstant arguments on SDL functions

Hello,

I was writing a wapper for text on C++, using SDL_ttf, and had some
problems with a const method that returns the heigh of the rendered text.
My text implementation uses a vector of SDL_Surface*, each containing one
line. When drawing on any target surface, I blit each of these surfaces,
one below the others, using a vertical value returned by
TTF_FontLineSkip(). On that method to return the height of the rendered
text, I do a multiplication of the number of lines by that line skip value.
But, since it’s a const method, I can’t use TTF_FontLineSkip, as it
receives TTF_Font*, instead of const TTF_Font*.

Checking the source code on SDL_ttf, I didn’t see any read-only functions
with const arguments. I noticed the same thing on SDL functions such as
SDL_SaveBMP (receives const char* and why not also const SDL_Surface*?). Is
this as it is really supposed to be?

Roberto Fischer.

Checking the source code on SDL_ttf, I didn’t see any read-only functions
with const arguments. I noticed the same thing on SDL functions such as
SDL_SaveBMP (receives const char* and why not also const SDL_Surface*?). Is
this as it is really supposed to be?

For a long time, people have been thinking about null-terminated strings
as “const char *” … immutable buffers of indeterminate length that
someone else allocated.

People haven’t been thinking this way about struct pointers, or general
const-correctness, for nearly as long.

Lots of these could be retrofitted into SDL 1.2 without breaking API or
ABI compatibility, but no one’s really spent the time yet.

For now, if you need to concern yourself with existing SDL headers that
aren’t const correct, you should just do a const_cast and know that
the functions don’t overwrite data in cases where they shouldn’t.

–ryan.

A few monts ago, I did send a patch for exactly this problem, which
corrected the basic SDL_ttf functions’ const-ness of pointer args (some
of those which you’d think should be const can’t be due to caching of
glyphs within the struct). Should I resend this?On Fri, Sep 08, 2006 at 01:50:12AM -0400, Ryan C. Gordon wrote:

Checking the source code on SDL_ttf, I didn’t see any read-only functions
with const arguments. I noticed the same thing on SDL functions such as
SDL_SaveBMP (receives const char* and why not also const SDL_Surface*?). Is
this as it is really supposed to be?

[…]

Lots of these could be retrofitted into SDL 1.2 without breaking API or
ABI compatibility, but no one’s really spent the time yet.


Steaphan Greene
Lecturer, Computer Science, Binghamton University
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060908/b578cbc3/attachment.pgp

A few monts ago, I did send a patch for exactly this problem, which
corrected the basic SDL_ttf functions’ const-ness of pointer args (some
of those which you’d think should be const can’t be due to caching of
glyphs within the struct). Should I resend this?

Sure, thanks!

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

Here are the same changes in a new patch matched up against current SVN.
Let me know if you find problems, but I did test these on Debian/Sparc,
Debian/PPC, Debian/386, Debian/Amd64 and Windows:386, though only with
gcc. This was a few months ago though.On Fri, Sep 08, 2006 at 07:28:36AM -0700, Sam Lantinga wrote:

A few monts ago, I did send a patch for exactly this problem, which
corrected the basic SDL_ttf functions’ const-ness of pointer args
(some of those which you’d think should be const can’t be due to
caching of glyphs within the struct). Should I resend this?

Sure, thanks!

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment


Steaphan Greene
Lecturer, Computer Science, Binghamton University
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: SDL-ttf-sgreene-constify-1.1.patch.gz
Type: application/octet-stream
Size: 885 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060908/96823807/attachment.obj
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060908/96823807/attachment.pgp

…and just so it’s clear, my PGP signature on that last message was
valid, mailman likes to change the text of messages with attachments,
adding newlines, making it look like signatures are bad. This one
(which doesn’t have the actual attachment) should show all is fine.On Fri, Sep 08, 2006 at 01:02:01PM -0400, Steaphan Greene wrote:

On Fri, Sep 08, 2006 at 07:28:36AM -0700, Sam Lantinga wrote:

A few monts ago, I did send a patch for exactly this problem, which
corrected the basic SDL_ttf functions’ const-ness of pointer args
(some of those which you’d think should be const can’t be due to
caching of glyphs within the struct). Should I resend this?

Sure, thanks!

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

Here are the same changes in a new patch matched up against current SVN.
Let me know if you find problems, but I did test these on Debian/Sparc,
Debian/PPC, Debian/386, Debian/Amd64 and Windows:386, though only with
gcc. This was a few months ago though.


Steaphan Greene
Lecturer, Computer Science, Binghamton University
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060908/42bda028/attachment.pgp

Here are the same changes in a new patch matched up against current SVN.
Let me know if you find problems, but I did test these on Debian/Sparc,
Debian/PPC, Debian/386, Debian/Amd64 and Windows:386, though only with
gcc. This was a few months ago though.

I don’t have svn access on this machine, so I put it in Bugzilla:

 http://bugzilla.libsdl.org/show_bug.cgi?id=324

Sam will catch it on his next run through the bug list.

Thanks!

–ryan.