[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Weird workaround necessary for mescc-lib on ARM
From: |
Jan Nieuwenhuizen |
Subject: |
Re: Weird workaround necessary for mescc-lib on ARM |
Date: |
Mon, 15 Jun 2020 06:58:31 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
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