Re: [AD] Documentation update

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

> > The patch is mostly ok, but I would avoid to "hardcode" in the docs the
> > hardcoded value of the code because of the risk of a future discrepancy.
> 
> I disagree. If there's a hardcoded limit to the stringlength of
> a certain function, it's important to know what it is. If it's bad
> enough that we have to place a warning in the documentation, we should
> definitely list the actual length limit of the string. Otherwise a
> programmer has to dive into the allegro source to find out, or
> worse, use trial and error to find out what the limit is and hope that
> the program stops nicely when it is exceeded instead of running on
> with corrupted memory. (I assume there's an assert on exceeding the
> stringlength?) 
> 
> I suggest putting the limit in the documentation, and just making a
> note for the allegro developers (somewhere in the comments of the
> function or so) that the docs have to be updated when that limit
> changes.

Would it be feasable to put all hardcoded limits behind #defines in some
header file (say, allegro/limits.h>)? In that case, we could refer to the
preprocessor #define and the header file instead.

n this particular case, the limit is 512 bytes. Frankly, I don't see that go
wrong except on insane resolutions with an exceptionally tiny font and a lot
of unicode characters. In other words, I think the chances of hitting this
limit are reasonably small (dangerous words, I know).

Evert

-- 
Evert Glebbeek, Physics student
Faculty of Science, University of Amsterdam
Institute for Theoretical Physics, room W3.013
e-mail: eglebbk@xxxxxxxxxx   tel. 525 5738
www: http://www.science.uva.nl/~eglebbk/