[email protected] said: > Sure would have been nice if we could have crossported Classic's fix for the > ^C bug in ntpq, though.
That particular bug isn't a big deal or somebody would have worked on it sooner. The real question is are we going to track fixes from NTP Classic and if so who, how, when, etc? There were a lot of patches released in the past few days. I haven't scanned them. I don't think anybody has reviewed all the changes since the fork. I looked into the ^C tangle. I'm trying to do it from scratch rather than blindly copy the new code. Maybe I'll learn enough to understand why the new code seems so complicated. It should be simple. The general idea is that the code that calls the command dispatcher does a setjmp and sets a flag for the ^C signal handler. If the flag is on, the signal handler does a longjmp to bail from the command. I put a printf in the top of the signal handler. The problem I'm seeing is that the ^C handler goes away after the first jump. If it doesn't jump, it keeps on working. An additional complication is that readline sets a bunch of signal handlers. I haven't investigated. Since it isn't mentioned in the man page, I assume it puts things back the way they were and/or calls the old signal handler. I tried blindly setting the signal handler again but that didn't fix it. That's as far as I got before it was time for sleep. Maybe it's masked? I've spent some time googling but haven't found anything interesting yet. Are there any obvious gotchas associated with signals and longjmp that I should know about? I'm working on Linux/Fedora. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
