Click here to Skip to main content
15,795,398 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hi folks. I need a review of a function I wrote that is suspected to perhaps have a bug in it - off by one is the most likely culprit, but I can't find it.

It is part of a const_buffer_stream class I use to read data off an array. For reasons I cannot use iostream classes.

Basically, it seems to be seeking to the wrong position when reading single bytes out of it. (calling read() with a size of 1. I'm not sure if it happens with larger values.

There could very well be no problem with this code. I just need more eyes to rule it out because as per my previous question (Indexing into a bitmap problem)[^] it was determined that the bug was deeper in my code.

What I have tried:

This function reads a portion of memory out of a const byte array. It's part of a larger const_buffer_stream class. It holds a buffer, a cursor position, and the size.

It returns the number of bytes read (which appears to work)

m_current the current offset into the buffer, as a pointer.
m_size the size of the buffer
m_begin the beginning of the buffer, as a pointer
size_t const_buffer_stream::read(uint8_t* destination,size_t size) {
    if(nullptr==m_current || nullptr==destination || size==0)
        return 0;
    size_t offs=m_current-m_begin;
        return 0;
        size = (m_size-offs);

    return size;
Updated 29-Aug-23 4:39am
CPallini 21-Aug-23 8:40am    
This is not the function you are calling in the linked page. The signature is different.
Probably you are using a wrapper, there.
honey the codewitch 21-Aug-23 8:40am    
I am indeed but it's just this: *in_out_size=stm->read(buffer,*in_out_size); return gfx_result::success;

Edit: I think I just found the bug!
Edit 2: Nope.
CPallini 21-Aug-23 8:51am    
Then I am not able to see any bug in your code. Possibly we need to compare it with the seek_data one (possibly I am doing bad assumptions. That is I assume a flat buffer containing the whole imagine, pointers declared as uint8_t *, etc...).
honey the codewitch 21-Aug-23 14:56pm    
the seek_buffer is similarly a thin wrapper. I'm confident in the seek code since I use it extensively for rendering straight out of TrueType font files, in maybe hundred projects now. It's rock solid. I think. :~
CPallini 21-Aug-23 15:40pm    
Then I would try (if you cannot debug by other means) to render a glyph with a very well known pattern (in order to know exactly where memory is going to).

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900