All:
I find it interesting that in REXX , its really easy to handle strings ..in
fact to me pretty simple.
Maybe because I very very familar with Rexx since it came out. Why cant C and
C++ be this way without going thru all the gyrations.
BTW here is a find string piece of code thats neat.
int find_substr(char *listPointer, char *itemPointer)
{
int t;
char *p, *p2;
for(t=0; listPointer[t]; t++) {
p = &listPointer[t];
p2 = itemPointer;
while(*p2 && *p2==*p) {
p++;
p2++;
}
if(!*p2) return t;
}
return -1;
}
This i found while trrying to make sense out of what I was doing with a control
file being parsed..
Scott J Ford
Software Engineer
http://www.identityforge.com/
________________________________
From: Bernd Oppolzer <bernd.oppol...@t-online.de>
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, September 5, 2012 11:46 AM
Subject: Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
Good point.
Many of you out there seem to dislike C for such reasons like that
discussed here: you have to take more responsibility for manageing
the lengths of the used buffers etc. - but the same people often like
ASSEMBLER, where the chance to put errors in your program is
much higher.
My opinion is: if you handle C carefully and you know about its pitfalls,
it can be a really great implementation language for software that is
targetted not far from the operating system, that is, tools, compilers,
parsers, db systems, embedded applications etc. - but it works also
for commercial or scientific application systems. One of its biggests
strengths is portability. I work with C now for almost 20 years
(and with PL/1, ASSEMBLER, Fortran, Pascal, even COBOL, REXX etc.),
and I like C very much. It is possible to write secure programs in C,
if you follow some rules, for example when using string functions.
C++ is another thing - I would strongly recommend to make a difference.
There are too much strange things happening "under the cover", and I
don't like it, if the programming language does things that I'm not
aware of.
Kind regards
Bernd
Am 05.09.2012 17:10, schrieb Anne & Lynn Wheeler:
> paulgboul...@aim.com (Paul Gilmartin) writes:
>> You, Lynn, and John G. are correct to distrust null-terminated strings.
> re:
> http://www.garlic.com/~lynn/2012l.html#67 Strings (hijacked from: The IBM
> zEnterprise EC12 announcment)
>
> in lots of discussions about C language string&buffer conventions being
> one the primary sources of programming errors ... there were analogous
> with careful drivers never having accidents and therefor there are no
> need for bumpers, safety glass, crash zones, seatbelts, padded
> dashboards, airbags, etc.
>
> the more straight-forward analysis is that buffer length management is
> left to the programmer ... always having to manually manage whether the
> implicit length (of null terminated string) fits within target storage
> area. I've compared it to assembler language programming where a major
> manual effort on the programmer was managing register contents ... and
> mis-managed register contents has been major assembler programming error
> ... especially in complex programs with large number of code paths
> ... and at any particular point in execution ... did all possible
> execution paths correctly initialize registers.
>
> It turns out that one of the benifits attributed for moving to
> C-programming ... is it allows system level programming while
> alleviating manual effort of the programmer managing the register
> contents. However, it has trade-off the elimination of the manual
> register content management effort with the buffer length manual
> management effort.
>
> Long ago and far away (in the very earliest days of rexx before released
> to customers)... I wanted to demonstrate the power of REXX ... and
> selected IPCS ... which was a large, assembler implemented application.
> Objective was to completely re-implemented IPCS in REXX ... working
> half-time over 3month period ... with the new implementation having ten
> times the function and with ten times the performance (some coding
> slight of hand to make an application in REXX run ten times faster than
> corresponding application in assembler). I finished early ... so I
> started doing analysis of kinds of failures and their failure signatures
> ... developing an augmented library of IPCS procedures that could be
> automated to look for the various kinds of failure scenarios. Misc.
> past posts mentioning DUMPRX
> http://www.garlic.com/~lynn/submain.html#dumprx
>
> I had assumed that it would be released to customers as IPCS replacement
> ... which never happened for whatever reason ... although it eventually
> came to be used by all internal datacenters and nearly all customer
> support PSRs. I eventually managed to get approval for making
> presentation at user group meetings about how it was implemented ... and
> within a couple of months, similar implementations started to appear
> from other vendors.
>
> Two of the most common were 1) anomolous code path failure to establish
> register contents (required at later point) and 2) dangling buffer
> pointers (aka asynchronous operation using pointer to storage area that
> was no longer active ... the particular storage area no longer active
> and/or re-allocated for some other purpose).
>
> Most higher-level languages eliminate manual programmer effort in
> managing register contents. One of the characteristics claimed for
> languages like Java & LISP is having eliminated programmer manual
> managed storage ... no only doesn't have C-language buffer length like
> problems ... but also has eliminated dangling pointer problems.
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
