Re: Weird workaround necessary for mescc-lib on ARM

[Jan Nieuwenhuizen]

Danny Milosavljevic writes:

>> Could it be that ungetc tries to unget EOF?  In that case the man page
>> of ungetc says that it will cast it to unsigned char (and thus it will
>> actually unget 255).

It doesn't look like it

--8<---------------cut here---------------start------------->8---
int
fdungetc (int c, int fd)
{
  __ungetc_init ();
  if (c == -1)
    return c;
--8<---------------cut here---------------end--------------->8---

> It's actually reaching this point:
>
> int
> unreadchar (int c)
> {
>   if (__stdin >= 0)
>     return fdungetc (c, __stdin);
>   <------ here, with c == -1

Oh, a string port!  And before we get into Mes C Lib!
Right...I didn't think about that at all...

>   SCM port = current_input_port (); 
>   SCM string = STRING (port);
>   size_t length = LENGTH (string);
>   char *p = CSTRING (string);
>   p--;
>   string = make_string (p, length + 1);
>   p = CSTRING (string);
>   p[0] = c;
>   STRING (port) = string;
>   return c;
> }

Weird...it seems that both the encountering EOF check is missing here
(where is "return -1"), as well as the "don't unget EOF"?

Very strange how this only pops-up on ARM, but it looks fishy anyway.

> (gdb) bt
> #0  unreadchar (c=-1) at src/posix.c:82
> #1  0x00020d98 in reader_read_identifier_or_number (c=-1) at src/reader.c:107
> #2  0x00021034 in reader_read_sexp_ (c=109, a=1) at src/reader.c:155
> #3  0x0002122c in read_env (a=1) at src/reader.c:192
> #4  0x00020a70 in read_input_file_env (a=9001) at src/reader.c:43
> #5  0x0001ac18 in eval_apply () at src/mes.c:1120
> #6  0x0001eab0 in main (argc=31, argv=0xbefff004) at src/mes.c:1871

Janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com