Re: strcmp vs strncmp question
Wel. had you looked at the second hit (really near the top, so boredom should not have set in yet) searching for why it was a hit you would have seen several instances of str*** func calls being replaced by strn*** func when the str ones were unsafe. Seeing that it was all about a CERT vulnerability report one would have assumed that a student of the topic would have gotten some insight into why these changes were made. Well too bad you are wrong Rod, but then you had to go insult him as well, didn't you. The head tells you that buffer overflows were an issue as they often are when str funcs are used unsafely. Not in this case. He found a real mistake. What exactly was your contribution to this? OH right. You were insulting with any cause. I'm sure that a good STFA would have found some insights from Theo and others and you really should have donee your homework there before asking about such a frequent topic. Mailing list netiquette. PEOPLE LIKE YOU, jumping on people who actually find real bugs, are the REAL problem with our mailing lists. He found a real bug. You just yelled and yelled and are an ass for it.
Re: strcmp vs strncmp question
Rod.. Whitworth wrote: /* Made up example of course */ - if (!strcmp(buf,n/a)) + if (!strncmp(buf,n/a,3)) you would have seen several instances of str*** func calls being replaced by strn*** func when the str ones were unsafe. Seeing that it The one has little to do with the other. What if buf, in the made-up example, contains n/abc? strcmp() says it's not the same, while the strncmp() line above does. Either function requires a valid, NUL-terminated C string, and both need to be smart enough to not read past that NUL (and they are.) I highly doubt that a str?cmp() fix ever went in like that, unless the different behavior was desired. It would be nice if Patrick could mention what he specifically means, because such a patch would most likely be wrong if it went in as an errenous safe string function replacement attempt. I grepped the ports tree patches. There are at least 10 of these bad patches. Someone should go delete them.
Re: UPDATE: lang/python
On 11/11/05, Aleksander Piotrowski [EMAIL PROTECTED] wrote: Hi Here goes lang/python update. Please test and comment. Thanks. Regression tests pass for me on i386, macppc and amd64. I have also tried a couple of py- modules that seem to work correctly. Eric.
Re: strcmp vs strncmp question
In the meantime, we're a few posts down the road from the original question, and I haven't seen any answer; neither on the list, nor on the Net. I suppose it has something to do with strcmp continuing to compare until it finds a char with value 0, but I can think of many situations where this wouldn't occur (it certainly shouldn't be an issue if all strings are always 0-terminated). So, I second patrick's question, and I would ask that someone either answer the question or provide a link to an answer. If it is indeed such a frequently asked question, it shouldn't be too hard to find a FAQ entry or mailing list post that answers it, right? Indeed, it's Rod who decided he knew what he was doing, and had to offend someone who was right. Sad, really... As already said, the obvious answer to the question is that most of these patches are plain wrong. I'm surprised they haven't been fixed yet...
Re: strcmp vs strncmp question
Rod.. Whitworth wrote: /* Made up example of course */ - if (!strcmp(buf,n/a)) + if (!strncmp(buf,n/a,3)) you would have seen several instances of str*** func calls being replaced by strn*** func when the str ones were unsafe. Seeing that it The one has little to do with the other. What if buf, in the made-up example, contains n/abc? strcmp() says it's not the same, while the strncmp() line above does. Either function requires a valid, NUL-terminated C string, and both need to be smart enough to not read past that NUL (and they are.) I highly doubt that a str?cmp() fix ever went in like that, unless the different behavior was desired. It would be nice if Patrick could mention what he specifically means, because such a patch would most likely be wrong if it went in as an errenous safe string function replacement attempt. Moritz
Re: strcmp vs strncmp question
--- Rod.. Whitworth [EMAIL PROTECTED] wrote: On Sun, 13 Nov 2005 17:22:42 -0800 (PST), patrick ~ wrote: /* Made up example of course */ - if (!strcmp(buf,n/a)) + if (!strncmp(buf,n/a,3)) Is there a real value in doing this? I don't see it. Can someone shed some light on this for me please. Are you just trolling? If not, how come you have not been looking in the archives? Mrs Google can help you too: http://justfuckinggoogleit.com/search?q=strncmp+openbsd+why My question was meant to be a very general one about why we patch 3rd party software just to replace a standard C function with another one which gives exactly the same result most of the time, and in some instances could give *undesired* results, i.e., may adversely change the behavior of the program. Your suggested google query resulted to nothing useful, other than a page with an awk script counting string function usage in openbsd source code. I wonder if you even bothered to try the link yourself before suggesting it? Someone else, who emailed me in private, was a bit upset that my message lacked any specifics in regard to which port I was referring to. I was trying to keep the question very general and not specific to any particular port. But if you must know I am looking at graphics/p5-Image-EXIF on a 3.7-stable system (my 3.8 CDs are still on my book shelf waiting for me to get around to upgrading a few machines). g'nite, --patrick // don't cc: me. i'm subscribed __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Re: UPDATE: lang/python
On Fri, Nov 11, 2005 at 04:48:28PM +0100, Aleksander Piotrowski wrote: Hi Here goes lang/python update. Please test and comment. Thanks. I tested on i386 and got 1 error during regression checks: test test_compare produced unexpected output: ** *** lines 102-149 of actual output doesn't appear in expected output after line 101: + ERROR: 1 -1 -1965125748 2123489356 + ERROR: 1 -1 -1965125748 2123489420 + ERROR: 1 -1 -1965125748 2123489388 + ERROR: 1 -1 -1965125748 2123489324 + ERROR: 1 -1 -1965125716 2123489356 + ERROR: 1 -1 -1965125716 2123489420 + ERROR: 1 -1 -1965125716 2123489388 + ERROR: 1 -1 -1965125716 2123489324 + ERROR: 1 -1 -1965125652 2123489356 + ERROR: 1 -1 -1965125652 2123489420 + ERROR: 1 -1 -1965125652 2123489388 + ERROR: 1 -1 -1965125652 2123489324 + ERROR: -1 1 2123489356 -1965125748 + ERROR: -1 1 2123489356 -1965125716 + ERROR: -1 1 2123489356 -1965125652 ... Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Re: If you're desperate to run clisp...
Sorry, I messed up this part: On Mon, Nov 14, 2005 at 10:31:24PM -0500, Andrew Sveikauskas wrote: I was able to get clisp working like this: cd /usr/ports/lang/clisp make configure cd w-clisp-2.33.2p0/clisp-2.33.2/src/malloc ar cq /usr/local/lib/libgmalloc.a cd - [ Add -lgmalloc to LIBS in w-clisp-2.33.2p0/build-i386/Makefile ] make install The part with the ar line should of course read: gcc -I. -c gmalloc.c ar cq /usr/local/lib/libgmalloc.a gmalloc.o
