Re: Why doesn't autoconf like our /bin/sh?
On Sun, 9 Mar 2008, Mike Meyer wrote: [...] So there are at *least* three things that could be considered broken, in that changing them would fix the problem I encountered. 1) Our /bin/sh isn't classified as Definitely usable. 2) zsh is Not usable. 3) zsh is classified as Maybe usable. #1 could be fixed on our side, if we understood why it wasn't usable. It could also be fixed by the autoconf folks. #2 has to be fixed by the zsh folks. #3 has to be fixed by the autoconf folks. Zsh has a large number of configuration settings that can make it more or less sh(1)-compatible. I've been bitten by SH_WORD_SPLIT, which defaults to being incompatible, IIRC. Since zsh is my interactive shell of preference, I spent a few minutes trying to reproduce your problems, but failed. Perhaps there is something in your .z* config files that make things go awry? $.02, /Mikko ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pls sanity check my semtimedop(2) implementation
On Sun, 13 Jul 2008, Michael B Allen wrote:
Hi,
Below is a semtimedop(2) implementation that I'm using for FreeBSD. I
was hoping someone could look it over and tell me if they think the
implementation is sound.
The code seems to work ok but when stressing the FreeBSD build of my app
I have managed to provoke errors related to concurrency (usually when a
SIGALRM goes off). The Linux build works flawlessesly so I'm wondering
about this one critical function that is different.
At the very least you need to check errno when semop() returns -1.
Unless it is EINTR, you have other problems.
Also, if there is any other code using the timer across this function
call, you have race conditions between changing the signal handler and
setting the timer. Even if there is no other use of the timer across
this function, resetting the signal handler before disarming the timer
leaves you open to the signal being handled by the default handler
which will make the process exit.
$.02,
/Mikko
Is there any reason why I would want to use ITIMER_VIRTUAL /
SIGVTALRM instead of ITIMER_REAL / SIGALRM?
Or perhaps I should be using a different implementation entirely?
Mike
int
_semtimedop(int semid,
struct sembuf *array,
size_t nops,
struct timespec *_timeout)
{
struct timeval timeout, before, after;
struct itimerval value, ovalue;
struct sigaction sa, osa;
int ret;
if (_timeout) {
timeout.tv_sec = _timeout->tv_sec;
timeout.tv_usec = _timeout->tv_nsec / 1000;
if (gettimeofday(&before, NULL) == -1) {
return -1;
}
memset(&value, 0, sizeof value);
value.it_value = timeout;
memset(&sa, 0, sizeof sa);
/* signal_print writes the signal info to a log file
*/
sa.sa_sigaction = signal_print;
sa.sa_flags = SA_SIGINFO;
sigemptyset(&sa.sa_mask);
sigaction(SIGALRM, &sa, &osa);
if (setitimer(ITIMER_REAL, &value, &ovalue) == -1) {
sigaction(SIGALRM, &osa, NULL);
return -1;
}
}
ret = semop(semid, array, nops);
if (_timeout) {
sigaction(SIGALRM, &osa, NULL);
if (setitimer(ITIMER_REAL, &ovalue, NULL) == -1) {
return -1;
}
}
if (ret == -1) {
if (_timeout) {
struct timeval elapsed;
if (gettimeofday(&after, NULL) == -1) {
return -1;
}
_timeval_diff(&after, &before, &elapsed);
if (timercmp(&elapsed, &timeout, >=))
errno = EAGAIN;
}
return -1;
}
return 0;
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's
Hi Garrett,
On Fri, 16 Jan 2009, Garrett Cooper wrote:
On Fri, Jan 16, 2009 at 12:58 AM, Garrett Cooper wrote:
On Fri, Jan 16, 2009 at 12:57 AM, Christoph Mallon
wrote:
Garrett Cooper schrieb:
Good point. I modified the source to do that.
Thanks,
-Garrett
You should reply to all so the discussion stays on the list.
Yeah, that was a goofup on my part. Go-go Gmail web interface!
-Garrett
Hmmm... looks like the strerror issue it could be a serious bug:
Add #include .
Without it you don't get the strerror() prototype, so the return value
defaults to an int. Thus the compiler will truncate the pointer value
to junk. The crash happens when formatting the output.
Compile with -Wall and pay attention to warnings (or use -Werror)
to catch these things.
$.02,
/Mikko
#include
#include
#include
int
main()
{
struct stat sb;
int o_errno;
if (stat("/some/file/that/doesn't/exist", &sb) != 0) {
o_errno = errno;
printf("Errno: %d\n", errno);
err(errno, "%s", strerror(o_errno));
}
return 0;
}
[gcoo...@optimus ~]$ ./badfile
Errno: 2
badfile: Segmentation fault: 11 (core dumped)
I rebuilt my kernel and installed it, and I rebuilt world, but
haven't installed it yet though, so let me reboot the amd64 machine
and see what happens (may be a mismatched ABI issue)...
Cheers,
-Garrett
___
freebsd-am...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Bug in tcp wrappers?
Hi Chris,
On Fri, 13 Mar 2009, Chris St Denis wrote:
I think I've found a bug in libwrap/tcpwrappers.
I think so too :) See below.
Before filing an actual bug report I want to get some feedback here
first.
A hosts.allow file with ~1000 ips on a single line (Haven't experimented with
other quantities yet), causes network daemons that use libwrap stop accepting
incoming network connections and use 100% cpu on an incoming connection.
This problem appeared because sshguard placed a large number of IPs in my
hosts.allow file triggering this bug.
I've left the affected daemons for a long period of time (once about 8 hours)
and they don't seem to come back, so I think this is more than just it taking
a while to loop through a 1000 item array of IPs
The production system that was affected is FreeBSD 7.0-32bit
Test system is FreeBSD 7.1-32bit
Example hosts.allow file (IPs are randomly generated for purposes of example)
sshd : 112.110.123.63 113.11.2.126 113.11.8.6 113.19.19.22
113.197.48.68 116.48.108.244 116.48.11.19 : deny
ALL : ALL : allow
top output of affected system. sshd wcpu slowly crawls up to 100% over about
30 seconds or so.
crash# top
last pid: 692; load averages: 0.08, 0.04,0.04
up
0+00:12:13 15:42:30
24 processes: 2 running, 22 sleeping
CPU: 49.7% user, 0.0% nice, 0.2% system, 0.2% interrupt, 49.9% idle
Mem: 9304K Active, 6004K Inact, 21M Wired, 32K Cache, 10M Buf, 947M Free
Swap: 1995M Total, 1995M Free
PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU
COMMAND
691 root1 1030 5760K 3660K CPU1 1 0:04 33.98% sshd
672 root1 40 8436K 3888K sbwait 1 0:00 0.00% sshd
677 cstdenis1 200 4460K 2288K pause 0 0:00 0.00% csh
682 root1 200 5484K 2632K pause 0 0:00 0.00% csh
675 cstdenis1 440 8436K 3896K select 0 0:00 0.00% sshd
A backtrace shows
crash# gdb /usr/sbin/sshd 691
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-marcel-freebsd"...
Attaching to program: /usr/sbin/sshd, process 691
Reading symbols from /usr/lib/libssh.so.4...done.
Loaded symbols for /usr/lib/libssh.so.4
Reading symbols from /lib/libutil.so.7...done.
Loaded symbols for /lib/libutil.so.7
Reading symbols from /lib/libz.so.4...done.
Loaded symbols for /lib/libz.so.4
Reading symbols from /usr/lib/libwrap.so.5...done.
Loaded symbols for /usr/lib/libwrap.so.5
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
0x28373225 in fgets (buf=0xbfbfe67b "", n=1, fp=0x283b8040) at
/usr/src/lib/libc/stdio/fgets.c:56
56 {
(gdb) bt
#0 0x28373225 in fgets (buf=0xbfbfe67b "", n=1, fp=0x283b8040) at
/usr/src/lib/libc/stdio/fgets.c:56
#1 0x281124ee in xgets (ptr=0xbfbfe67b "", len=1, fp=0x283b8040) at
/usr/src/lib/libwrap/../../contrib/tcp_wrappers/misc.c:38
#2 0x28111410 in table_match (table=0x28112c5c "/etc/hosts.allow",
request=0xbfbfeb14)
at
/usr/src/lib/libwrap/../../contrib/tcp_wrappers/hosts_access.c:162
#3 0x28111540 in hosts_access (request=0xbfbfeb14) at
/usr/src/lib/libwrap/../../contrib/tcp_wrappers/hosts_access.c:132
#4 0x08052b39 in main (ac=2, av=0xbfbfeecc) at
/usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:1843
(gdb) bt
#0 0x28373225 in fgets (buf=0xbfbfe67b "", n=1, fp=0x283b8040) at
/usr/src/lib/libc/stdio/fgets.c:56
#1 0x281124ee in xgets (ptr=0xbfbfe67b "", len=1, fp=0x283b8040) at
/usr/src/lib/libwrap/../../contrib/tcp_wrappers/misc.c:38
#2 0x28111410 in table_match (table=0x28112c5c "/etc/hosts.allow",
request=0xbfbfeb14)
at
/usr/src/lib/libwrap/../../contrib/tcp_wrappers/hosts_access.c:162
#3 0x28111540 in hosts_access (request=0xbfbfeb14) at
/usr/src/lib/libwrap/../../contrib/tcp_wrappers/hosts_access.c:132
#4 0x08052b39 in main (ac=2, av=0xbfbfeecc) at
/usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:1843
(gdb) q
The program is running. Quit anyway (and detach it)? (y or n) y
Detaching from program: /usr/sbin/sshd, process 691
A few questions
1. Is this a known issue of any sort? I've done some searching on it, but
haven't found anything of interest.
2. Should this be reported to FreeBSD bug tracker, or to libwrap (or both)?
Basically, is FreeBSD's libwrap (more or less) in sync with the main one, or
is it completely separate?
When given an input line of more than 2k bytes, libwrap ends up in an
infinite loop in xgets(), calling fgets() with a read length of one.
As fgets() reads the length minus one characters, it will keep
"reading"
Re: Bug in tcp wrappers?
On Sun, 15 Mar 2009, Nate Eldredge wrote: On Sun, 15 Mar 2009, Mikko Työläjärvi wrote: The real fix involves rewriting chunks of the libwrap code, or finding a version where someone has already done so. It doesn't seem like it should be too bad. xgets is only called in three places. It would be easy enough to replace it with something like glibc's getline(3), that uses realloc to size a buffer appropriately. Yes, it should be pretty straightforward. I just noticed that openbsd applied a (better) variant of my patch for the infinite loop problem in 2003. They didn't address the "line too long" problem, though. If nobody else feels like doing this, maybe I will. And if you don't, I just might :) /Mikko___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Rejecting a connection: is accept(2) correct?
AFAIK there is no portable way to reject incoming connections without calling accept(). However, accept(2) states: One can obtain user connection request data without confirming the connection by issuing a recvmsg(2) call with an msg_iovlen of 0 and a non-zero msg_controllen, or by issuing a getsockopt(2) request. Similarly, one can provide user connection rejection information by issuing a sendmsg(2) call providing only the control information, or by calling setsockopt(2). Is this really true? A quick experiment with recvmsg() seems to indicate it is not, at least not for TCP sockets. ? /Mikko P.S. Anybody who claims that this works is encouraged to provide proof in the form of code... :-) Mikko Työläjä[EMAIL PROTECTED] RSA Security To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Rejecting a connection: is accept(2) correct?
On Thu, 14 Dec 2000, David Malone wrote:
> On Thu, Dec 14, 2000 at 09:12:18AM -0800, Mikko Työläjärvi wrote:
>
> > Is this really true? A quick experiment with recvmsg() seems to
> > indicate it is not, at least not for TCP sockets.
>
> I think this applies after you have accepted the connection. You
> can call getpeername() to choose what to do about the call. You
> can immediately close the connection if you don't want to deal with
> it.
Umm.. yes, that is the normal way of doing things, but that is not
what (I think) it says in the man-page, which is why I was wondering.
"One can obtain user connection request data without confirming the
connection..." (and then goes on about recvmsg(),sendmsg() and
{set,get}sockept() with little or no details).
It does not state which socket this is supposed to operate on: the
listening socket, or the new one. If it is the listening socket,
it would be an innovation, and open up assorted new possibilities.
If it is the new socket, it is old news :-)
/Mikko
Mikko Työläjä[EMAIL PROTECTED]
RSA Security
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD 6.0 default pty/tty-limit (256) OFF!
Hi Antti, I need patch to raise FreeBSD 6.0 default pty/tty-limit (256) UP or OFF. In shell-production usage, that limit is ridiculous, there must be stop to this and put PTY-limits off! I changed my servers operating systems moment ago from Linux to FreeBSD thinking that FreeBSD could be more better, but how this can be possible, that so important think like PTYs are limited to so low?? every UNIX has more ptys. This is a long standing problem, as is evident from kern/25866 [1] from 2001. A more recent report is standards/90896 [2], wich also contains a patch. I'd suggest you try the patch and provide feedback to the bug report. $.02, /Mikko 1) http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/25866) 2) http://www.freebsd.org/cgi/query-pr.cgi?pr=standards/90896 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Synaptics touchpad extendid support.
First, many thanks to Marcin. On Sun, 5 Jan 2003, Rahul Siddharthan wrote: > Marcin Dalecki wrote: > > Here is my first cut at support for the Synaptics touchpads, which are > > commonly used on notebooks. Contrary to the default "Windows > > installation mode" those devices come up at boot, this is enabling > > full support for all buttons present on the device and works nicely > > with moused together. > > I just tried it. Couple of issues: Me too. > 1. The "speed" of the pointer on the screen is way faster now. I > corrected that with some XF86Config options. Easy enough to fix with scaling. To me the pointer also feels slightly "detached" or lagging, as if attached to my finger with a rubberband... Some kind of filtering, or an artifact from the absolute->relative conversion, perhaps. Oh, well, it works well enough. > 2. The pad has 4 buttons; left and right work as before. In between, > there are a small up and down button. Now the up button acts as the > middle button (button 3?) -- ie I can paste with it. The down button > still does nothing. I tried playing with the moused parameters and > the XF86Config ZAxisMapping settings, to no avail. > > 3. Earlier, tapping on the touchpad would emulate a left click. It > no longer does anything (not sure whether that's good or bad). I used to hate tapping, but now when it is gone, I can't decide whether I want it or not :-) A look in the specs show that tap processing has to be done entirely in software when the touchpad is in this mode, i.e. not just a matter of twiddling a bit. > What I'd like is to emulate 3 buttons with simultaneous left-right > clicking, as before; have the "up" button behave like scrolling a > mousewheel up; and have the "down" button behave like scrolling a > mousewheel down. I thought the > Option "ZAxisMapping" "4 5" > in XF86Config, and > moused -m 4=3 -m 5=4 > would do it. But no luck (though the above moused options do stop the > up button from acting like a middle button). > > Any ideas, anyone? I just made it work (-current, XFree86 4.2.1). Like this: The buttons are 1/3 (left/right) and 4/2 (up/down). Looks like moused is incapable of both mapping physical button 2 to something and at the same time emulating a middle button as left+right (with the -3 flag). But the following works in X: * Make moused map up/down into buttons 4/5: moused -m 4=2 -m 5=4 -p /dev/psm0 -t auto * Make X do the rest. From XF86Config (for XFree 4.2): Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "Auto" Option "Device" "/dev/sysmouse" Option "Resolution" "100" Option "Emulate3Buttons" Option "Buttons" "5" EndSection This makes X handle emulation of the middle button. Hmm... looks like there already is a default ZAxisMapping. If you have problems, try adding Option "ZAxisMapping" "4 5" Now I have to decide whether I want this, or if I want a real middle button. Decisions, decisions... $.02, /Mikko To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: wait()/alarm() race condition
On Sun, 30 Mar 2003, Sean Hamilton wrote: > Dan Nelson wrote: > | Just make sure your signal handler has the SA_RESTART flag unset > | (either via siginterrupt() if the handler was installed with signal(), > | or directly if the signal was installed with sigaction() ), and the > | signal will interrupt the wait() call. > > Er, I think you've missed my problem. Or I'm not getting your solution. > > I'm concerned about this order of events: > > - alarm() > - wait() returns successfully > - if (alarmed...) [false] > - SIGALRM is delivered, alarmed = true > - loop > - wait() waits indefinitely > > This is incredibly unlikely to ever happen, but it's irritating me somewhat > that the code isn't airtight. Bad design. Surely there is some atomic means > of setting a timeout on a system call. My stock solution to this kind of problem is to turn those pesky signals into I/O and use an old fashioned select() loop to handle them; create a pipe(2), let signal handlers write one-byte "messages" (the signal number) into the pipe and then use select() to dequeue the events (signals) from the pipe. Select() has a timeout parameter you can play with to your hearts content, and provided you don't overflow the pipe, no events will get lost. You'd have to install a hander for SIGCHLD, of course. $.02, /Mikko ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proper behaviour for wait()?
On Fri, 30 May 2003, Paul Herman wrote:
> Just curious,
>
> anyone know what the "proper" behavior for wait() is when SIGCHLD
> is ignored? Is it simply undefined? Don't see anything mentioned
> in the wait(2) manpage one way or tother, and other OSes don't seem
> to agree much.
If you ignore SIGCHLD using sigaction(), and set the SA_NOCLDWAIT
flag, the child will automatically go away. On BSD derived systems,
if you ignore SIGCHLD using signal(3), and depend on the above
behavior, you tend to end up with a zombie.
SUSv3, says (under "sigaction"):
"SA_NOCLDWAIT
[XSI] If set, and sig equals SIGCHLD, child processes of the
calling processes shall not be transformed into zombie processes
when they terminate. If the calling process subsequently waits for
its children, and the process has no unwaited-for children that
were transformed into zombie processes, it shall block until all
of its children terminate, and wait(), waitid(), and waitpid()
shall fail and set errno to [ECHILD]. Otherwise, terminating child
processes shall be transformed into zombie processes, unless
SIGCHLD is set to SIG_IGN."
And in the "Signal Concepts" section (as part of an XSI extension):
"If the action for the SIGCHLD signal is set to SIG_IGN, child
processes of the calling processes shall not be transformed into
zombie processes when they terminate. If the calling process
subsequently waits for its children, and the process has no
unwaited-for children that were transformed into zombie processes, it
shall block until all of its children terminate, and wait(),
waitid(), and waitpid() shall fail and set errno to [ECHILD]."
This part does not mention the method of setting the handler to
SIG_IGN, so signal(3) should be able to get rid of zombies. That is
not true on FreeBSD.
The only way (except "for historical reasons") the above standards
excerpts would make sense to me, is if setting the SIGCHLD handler to
SIG_IGN always makes the system reap child processes, and if using
sigaction() with the SA_NOCLDWAIT flag would allow you to get signal
delivery together with automatic zombie reaping (i.e. handler gets
called, but wait() will fail).
But I've never seen that behavior described anyware, so that is
probably not the intent. Also, it does not work that way on FreeBSD:
once I've set the SA_NOCHLDWAIT flag, I don't get any SIGCGHLD
signals.
And now over to someone who actually knows what they're talking about... :)
$.02,
/Mikko
>
> -Paul.
>
> bash$ cat wait.c
> #include
> #include
> #include
> #include
> #include
>
> int main() {
> int status;
> pid_t pid = fork();
>
> if (!pid) { sleep(1); _exit(0); }
>
> signal(SIGCHLD, SIG_IGN);
> printf("waitpid() = %d\n", waitpid(pid, &status, 0));
> signal(SIGCHLD, SIG_DFL);
> return 0;
> }
> bash$ cc wait.c
>
> [FreeBSD 4.8]
> bash$ ./a.out
> waitpid() = 7553
> bash$
>
> [Linux 2.4.21]
> bash$ ./a.out
> waitpid() = 24536
> bash$
>
> [Darwin 6.6]
> bash$ ./a.out
> waitpid() = -1
> bash$
>
> [Solaris 8]
> bash$ ./a.out
> waitpid() = -1
> bash$
>
> [OpenBSD 3.3]
> bash$ ./a.out
> ...just hangs...
>
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: help needed-urgent
On Mon, 18 Aug 2003, DANDY King wrote: > hello > > > our product is DVR(digital video recorder), it runs on linux system. > i am sending very imp inofrmation to server through sockets. some time i am > getting full data, some time i am getting partial data. > i don't know reasons please advice. > client side we uses VC++ GUI. client sending data neatly. in client side > what i did And that is related to FreeBSD... how? > > while((nread = read(fd,buff,BUFFSIZE)) >0) > send(sockfd,buff,nread,0); > > in server same data should receive. Wrong. You are not qualified to work on that product before taking at least "socket network programing 101". Hint: "short write". > but some time i am receiveing full and some time 90% only > > please advice Please post the name of the "product" and the company you work for, so I can stay way clear of both. > > Dharanish > > _ > MSN Hotmail now on your Mobile phone. > http://server1.msn.co.in/sp03/mobilesms/ Click here. > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: testing for substrings in perl
On Sun, 5 Oct 2003, Dan Langille wrote:
> Hi,
>
> I have a perl regex to test if a file resides under a particular
> directory. The test looks like this:
>
> if ($filename =~ $directory) {
># yes, this filename resides under directory
> }
>
> This is working for most cases. However, it fails is the directory
> contains a +. For example:
>
> $filename = 'ports/www/privoxy+ipv6/files/patch-src::addrlist.c';
>
> $match = "^/?" . 'ports/www/privoxy+ipv6' . "/";
> if ($filename =~ $match) {
>print "found\n";
> } else{
>print "NOT found\n";
> }
>
> Yes, I can escapte the + in the directory name, but then I'd have to test
> for all those special regex characters and escape them too.
Or use quotemeta()...
> I think it might just be easier to do a straight comparison of the first N
> characters of the two strings where N = length of the directory name.
>
> Any suggestions?
...or the \Q operator. Thus:
$filename = 'ports/www/privoxy+ipv6/files/patch-src::addrlist.c';
$dir = 'ports/www/privoxy+ipv6';
if ($filename =~ m:^/?\Q$dir\E/:) {
print "found\n";
} else{
print "NOT found\n";
}
$.02,
/Mikko
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Thread-safe resolver [patches for review]
On Mon, 12 Aug 2002, Peter Wemm wrote: > Maxim Sobolev wrote: > > I also would like to hear from you whether or not you think that we > > need all those gethostbyXXX_r(3) functions. > > Yes. Because autoconf looks for them and will assume non-reentrancy if > they are not present. Also, for source compatability with linux and > solaris and just about everything else that implements this stuff. The > expectation is that gethostbyXXX is non-safe and that gethostbyXXX_r is > safe. If you can make the non_r versions safe then that is a bonus I guess. You are aware that Solaris's version of gethostbyname_r() has a different interface than Linux's (glibc 2.whatever) variant, and that both differ from AIX's gethostbyname_r()... right? Also, some systems (HP-UX 11 and Irix [not sure, though]) have a reentrant gethostbyname(), possibly alongside a _r version marked "obsolete". So, even though I agree that having _r versions might be useful, neither autoconf (which has to be smarter than just looking for a "_r" version), nor source compatibility should be considered the main reasons, IMHO. $.02, /Mikko Mikko Työläjä[EMAIL PROTECTED] RSA Security To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB support for new HP printers?
On Mon, 26 Aug 2002, Terry Lambert wrote:
> John Nielsen wrote:
> > > have a look at hpoj.sourceforge.net
> > > they plan FreeBSD USB support for a next release
> >
> > I've been all over the site and read some of the docs. The most useful
> > piece of information I found was this:
> >
> > "FreeBSD, NetBSD, and OpenBSD are not yet supported in USB mode, due to
> > missing functionality in the kernel "ulpt" driver (bidirectional I/O,
> > device ID retrieval, switching to 7/1/3, and HP channel-change-request)."
>
>
> I'm pretty sure that bidirectional I/O is supported, or there
> would be no network devices.
[...]
Though the USB stack handles bi-directional communication, ulpt does not:
Static struct cdevsw ulpt_cdevsw = {
/* open */ulptopen,
/* close */ ulptclose,
/* read */noread,< !
...
In -current, an input routine has been added, but all it does is
discard any data that comes from the printer.
$.02,
/Mikko
Mikko Työläjä[EMAIL PROTECTED]
RSA Security
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Just a wild idea
On Tue, 24 Sep 2002, Paul Schenkeveld wrote: > Hi Thomas, > > On Tue, Sep 24, 2002 at 01:31:59AM +0200, tho wrote: > > hi Paul, > > > > have you considered using a "file descriptor passing" based technique > > (section 14.7 of Stevens' UNPv1) ? > > > > you may have a process with suser privs which creates file descriptors > > (e.g. socket bind()ed to a particular address and port) on demand and then > > passes back the descriptor to the requesting (unprivileged) process through > > a unix domain socket > > I know this technique but the real issue is about many pieces of > standard software, like BIND named, sendmail, syslogd and so on. > So this technique, although very usable for new projects, will > not solve this problem. As long as the programs are dynamically linked, you can LD_PRELOAD a wrapper for bind() that passes the socket and address information to the privileged process that does the actual bind() call and replies with an errno value. It works. I've done it. $.02, /Mikko Mikko Työläjä[EMAIL PROTECTED] RSA Security To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IBM ATA Deskstars *without* tagged queueing?
On Thu, 26 Sep 2002, Bruce M Simpson wrote: > I bought a Deskstar 120GXP that *doesn't* appear to do tagged queueing. I > was wondering if anyone else had encountered such a thing. It's somewhat > annoying; generally I buy IBM drives for precisely the reason that they're > meant to support tagging. > > The device model ID is IC35L040AVVN07-0. There's more information about > these OEM drives here: > http://www.digit-life.com/articles/digests/hddreview-0602-ibm.html I've got the 60GB model x 2. Since 4.6 the system won't even boot with tagging enabled >:-( > The kernel reports it as (note no 'tagging' keyword):- > atapci0: port 0xf000-0xf00f at device 31.1 on pci0 > ad0: 39266MB [79780/16/63] at ata0-master UDMA66 Do you have hw.ata.tags="1" in /boot/loader.conf? It is "0" by default (check with "sysctl hw.ata.tags"). See ata(4). $.02, /Mikko To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [FreeBSD PR bin/15416] addr2line broken
On Wed, 20 Nov 2002, Joseph Scott wrote: > FreeBSD PR bin/15416 (addr2line is unable to find line > numbers) indicates that addr2line appears to be broken. This PR was > submitted at the end of 99 when 4.x was -current. It hasn't been touched > since. > > The PR gives a test case where addr2line appears to be broken. I > ran this exact test case on a 4-stable box and saw the same issue. The > version addr2line reports is 2.12.1 [FreeBSD] 2002-07-20. I tested it on > 5-DP2 and it appears to work correctly, the version there is 2.13 > [FreeBSD] 2002-10-10. > > What's the correct thing to do with this PR? The issue does > appear to be fixed in -current (with the newer addr2line). I suppose the > PR should at least be set to a status of patched. As the originator of that PR (the e-mail address in the PR is now defunct), I'd say close it. Nowadays the problem only seems to affect the "main" symbol, other functions are resolved as expected. Regards, /Mikko To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
