Re: Fast and Safe C Strings: User friendly C macros to Declare and use C Strings.

2007-04-20 Thread Anne Lynn Wheeler
://www.garlic.com/~lynn/2007h.html#41 Fast and Safe C Strings: User friendly C macros to Declare and use C Strings the initial implementation and would get about 44kbyte/sec consuming most of a 3090 processor. i then added the support for rfc1044 and some tuning tests at cray research was getting channel speed

Re: Fast and Safe C Strings: User friendly C macros to Declare and use C Strings.

2007-04-20 Thread Anne Lynn Wheeler
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. re: http://www.garlic.com/~lynn/2007h.html#41 Fast and Safe C Strings: User friendly C macros to Declare and use C Strings. http://www.garlic.com/~lynn/2007h.html

Re: Fast and Safe C Strings: User friendly C macros to Declare and use C Strings.

2007-04-17 Thread Shmuel Metz (Seymour J.)
In [EMAIL PROTECTED], on 04/17/2007 at 10:08 AM, Clem Clarke [EMAIL PROTECTED] said: What is needed is for ANSI to bite the bullet and fix the problem. The use of trailing zero as a delimiter, like the confusion between arrays and pointers, is omnipresent in the C world. I see no practical

Re: Fast and Safe C Strings: User friendly C macros to Declare and use C Strings.

2007-04-17 Thread Anne Lynn Wheeler
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. [EMAIL PROTECTED] (Shmuel Metz , Seymour J.) writes: The use of trailing zero as a delimiter, like the confusion between arrays and pointers, is omnipresent in

Re: Fast and Safe C Strings: User friendly C macros to Declare and use C Strings.

2007-04-16 Thread Clem Clarke
Hi Paul, The macros are not compatible (I suspect) with PL/I or BPX1*. For some years, using Borland compilers, I managed to get the 2 byte length field just in front of the string. I couldn't use a structure, which would have guaranteed the position because then the debugger and all the

Re: Fast and Safe C Strings: User friendly C macros to Declare and use C Strings.

2007-04-16 Thread Paul Gilmartin
In a recent note, Clem Clarke said: Date: Tue, 17 Apr 2007 10:08:37 +0800 What is needed is for ANSI to bite the bullet and fix the problem. Or for someone big, like IBM to do it, and force a standard change. (As an aside, there is a language called D, which has a length word for

Re: Fast and Safe C Strings: User friendly C macros to Declare and use C Strings.

2007-04-16 Thread Clem Clarke
Yes. I dropped the same message into a C newsgroup. Some of the people recognized the problem, but essentially they don't care, I think. I guess if you have heaps of computing power at your fingertips in the way of Linux boxes, and if they aren't doing the same sort of work as most Z/OS

Re: Fast and Safe C Strings: User friendly C macros to Declare and use C Strings.

2007-04-15 Thread Shmuel Metz (Seymour J.)
In [EMAIL PROTECTED], on 04/13/2007 at 03:11 PM, Clem Clarke [EMAIL PROTECTED] said: Some 20 years ago, it became clear that C strings were not as safe, nor as fast, as strings in PL/I, Assembler or Pascal. The same applies to C arrays in general. The confusion between arrays and pointers,

Fast and Safe C Strings: User friendly C macros to Declare and use C Strings.

2007-04-13 Thread Clem Clarke
Some 20 years ago, it became clear that C strings were not as safe, nor as fast, as strings in PL/I, Assembler or Pascal. The primary reasons are that one needs to find the current length of a string before or during a copy process - this is very time consuming. Secondly, there is no way of

Re: Fast and Safe C Strings: User friendly C macros to Declare and use C Strings.

2007-04-13 Thread Paul Gilmartin
In a recent note, Clem Clarke said: Date: Fri, 13 Apr 2007 15:11:45 +0800 I have spent some years studying this problem and have developed some User friendly C macros that solve the problem. These are reminiscent of the StrAllocCat, StrAllocCopy, et. al. family of string functions