From: "A. Sinan Unur" Newsgroups: comp.os.msdos.djgpp Subject: Re: Please add strrev proposal Date: 28 Sep 2001 22:52:23 GMT Organization: Cornell University Lines: 44 Sender: asu1 AT cornell DOT invalid (on slip-32-102-40-210.ny.us.prserv.net) Message-ID: References: NNTP-Posting-Host: slip-32-102-40-210.ny.us.prserv.net X-Trace: news01.cit.cornell.edu 1001717543 16780 32.102.40.210 (28 Sep 2001 22:52:23 GMT) X-Complaints-To: usenet AT news01 DOT cit DOT cornell DOT edu NNTP-Posting-Date: 28 Sep 2001 22:52:23 GMT User-Agent: Xnews/4.06.22 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Radical NetSurfer wrote in news:bit9rt8qih41716vvs42gavjrfmc1v8kh2 AT 4ax DOT com: > I've never had any problems with "bcc's" version of strrev(), odd or > even number of chars, 1-32 chars.... > gosh...there have actually been days I could of used a memrev() > (where 0x00 could be included) i would recommend compiling the code I posted. then see if the exhibited behavior is what you want. with the type of code for strrev you posted, int main(void) { char s[] = "string"; printf("%s\n%s\n", s, strrev(s)); return 0; } is NOT guaranteed to display string gnirts as you seem to think it should. further, what happens if i do strrev("string") under various optimization settings/different compilers? my point is, the function you propose, and the code you posted are not general enough. some applications may need that kind of functionality. in that case, you are better off writing your own specific version. just because something that is not so useful exists in other products is not a good reason to add it to djgpp. anyway, i think this is going to be my last post on the topic. sinan. -- -------------------------------- A. Sinan Unur http://www.unur.com/