Re: Huge numbers for incr passed to _sbrk

I have fixed the bug now. It turns out that I was using uint32_t types for
my sbrk implementation when I should have been using char* types. The
official Newlib documentation uses caddr_t in its sample implementation of
sbrk, which was confusing to me as that is a type I had never seen before.
I had to browse through a forum from 1999 to figure out that caddr_t is
just a typedef to char*.

I think it would help all new users of Newlib if the documentation used
char* instead of caddr_t, or at least had a sentence saying what caddr_t is.

On Thu, Aug 23, 2018 at 1:52 PM Bob Dunlop <[email protected]> wrote:

>
> On Thu, Aug 23 at 10:22, Michael Mamic wrote:
> > A similar incr value of huge proportions is passed to sbrk when Lua is
> > initialized. I need to find out why this is happening so I can adjust for
> > it.
>
> Are the library and syscall implementation being compiled with the
> same compiler flags and using a common header file for the function
> prototype ?
>
> A mismatch in type or parameter passing conventions between caller and
> callie could lead to these sorts of errors.  But then I'd have expected
> just about every function to be affected.
>
> The value seen in the syscall 1431656813 converted to hex is 0x5555596D.
> Now all those 5s make me think of stack or memory boundry guard values.
>
> --
>         Bob Dunlop
>