I wonder, however, if there
is another problem around
z38.c:254, like the one you
have mentioned here?
Probably - there are a couple of instances of sscanf %s%n there.
I've just submitted patch scanf-string-eof which should correct
all these.
I applied your patches, reverted the old
change to z36.c, and recompiled. Install
went smoothly, and now there are none
of the obvious errors as before, regarding
sscanf. However, there is a new issue -
the program sys-traps as it's about to
produce output. Here's the basic acid trace:
term% lout
Ah, on second thought, looking back at
that acid lstk() output, it seems that the
troublesome line is:
fprintf(out_fp, %hd %s, FontSize(currentfont, nilobj),
in z49.c For some reason, '%hd' is not
being handled properly (though from
fprintf(2), it seems that modifiers with
%h produce
in z49.c For some reason, '%hd' is not
being handled properly
You are right. The definition of va_arg macro in /386/include/ape/stdarg.h
is wrong. Try replacing it with the definition in /386/include/u.h and
then rebuilding /sys/src/ape/lib/ap/stdio
in z49.c For some reason, '%hd' is not
being handled properly
You are right. The definition of va_arg macro in /386/include/ape/stdarg.h
is wrong. Try replacing it with the definition in /386/include/u.h and
then rebuilding /sys/src/ape/lib/ap/stdio
Spot on!
Everything runs smoothly,
[3] The execution that fails is actually a crucial
part of the `make install' process. I've attached
the whole output of the build and install
processes.
The problem is in /sys/src/ape/lib/ap/stdio/vfscanf.c -- semantics of
%n is incorrect if an item is terminated by EOF (i.e. end of string
Ah! Thank you for this!
The initialization works
perfectly now.
I wonder, however, if there
is another problem around
z38.c:254, like the one you
have mentioned here?
I get the following (extra
debugging info removed)
when I try to do
cpu% cd doc/slides
cpu% lout -r2 all slides.ps
snip
cm:
