On Tue, Jul 04, 2006 at 11:57:13AM +0200, Matthias Andree wrote:
> Justin Pryzby <[EMAIL PROTECTED]> writes:
>
> > It notices that there's an rc file:
> > |open("/home/pryzbyj/.fetchmailrc", O_RDONLY) = 4
> >
> > WTF?
> > |ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0xafa04e58) = -1 ENOTTY
> > (Inappropriate ioctl for device)
>
> glibc at work, probably isatty() or equivalent to find out the default
> buffer size (line vs. fully buffered).
Nice
> > Huh? Yes, we are a process..
> > |kill(0, SIG_0) = 0
> > |close(4) = 0
>
> That's indeed a bug, and it's easy to fix (patch attached, description
> below). The fscanf() in fm_lock_state() returns EOF; which isn't handled
> in <= 6.3.4.
> I find the PID of 0 astonishing however. Is Debian's GCC different than
> SUSE's?
What compiler {,version} and optimization level are you using?
In a test, gcc-3.4 -O0, gcc-4.0 -O3, and gcc-4.0 -O1 results in sscanf
setting integers to zero, even if no valid input was read.
IIRC buffer initialization also changes.
This may, in fact, be a deliberate but otherwise unnecessary change by
the toolchain folks to break in an obvious way things which rely on
unfounded assumptions, rather than allowing them to work with the
author's $cc, but fail obscurely with others'.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
