Use lengths but make sure the string buffer is null terminated. On 29/06/2013, at 10:30 AM, zMan <[email protected]> wrote:
> Require both? That irritates BOTH groups, and seems to have the weaknesses > of both. I must be missing what you're saying... > > > On Fri, Jun 28, 2013 at 9:40 PM, David Crayford <[email protected]> wrote: > >> Why not do both? Use lengths and make sure the string is null terminated. >> That's how std::string works in C++ where you can call c_str() to return a >> null terminated string. >> >> On 29/06/2013, at 9:15 AM, zMan <[email protected]> wrote: >> >>> Right, but these kids don't seem to be. The argument I'm getting is "OK, >>> but even if we pass an explicit length, people will assume the return is >>> null-terminated". I say, "They'll learn"... >>> >>> >>> On Fri, Jun 28, 2013 at 8:29 PM, Charles Mills <[email protected]> wrote: >>> >>>> Yes, character arrays and an explicit length. C programmers are quite >> used >>>> to this, viz. memcpy() etc. >>>> >>>> Charles >>>> >>>> -----Original Message----- >>>> From: IBM Mainframe Discussion List [mailto:[email protected]] >> On >>>> Behalf Of zMan >>>> Sent: Friday, June 28, 2013 12:53 PM >>>> To: [email protected] >>>> Subject: Theology question: Parameter formats >>>> >>>> Suppose you're defining an API, to be callable from multiple languages, >>>> including C. You believe/assume that C will be the most common language >> on >>>> non-z platforms (probably reasonable, FSVO "reasonable"), but you also >> need >>>> to be callable on z. >>>> >>>> Would you: >>>> a) Design the API to pass data/length pairs >>>> b) Use null-terminated strings to keep the C people happy, and have to >>>> create some sort of layer for languages like COBOL to keep usage from >> that >>>> world sane? >>>> >>>> (Yes, I know about z' variables in COBOL, but people aren't used to and >> in >>>> my experience aren't fond of those. And there are a lot of languages out >>>> there to consider besides COBOL!) >>>> >>>> My contention is that C folks can surely understand the concept of >> passing >>>> a >>>> length, especially since C validates parameters -- that is, if a C >> person >>>> might expect to call SOMEFUNCTION(char*, char*) >>>> >>>> and instead the function definition is >>>> SOMEFUNCTION(char*, int*, char*, int*) >>>> they shouldn't exactly be confused. Surely they understand the >> *concept* of >>>> a length. >>>> >>>> But people are whining: "But this is how C works -- that's what strings >>>> are!". >>>> >>>> How do most other APIs deal with this? I've not really written >> applications >>>> this century (or, to be honest, the last one) -- always done systems >> stuff. >>>> >>>> As part of this discussion, I've had the epiphany that people don't >>>> *expect* to be able to call existing code from random languages--they >> think >>>> there will need to be some kind of shim layer. So they're quite >> surprised >>>> that as z folks, we expect an API to be callable from pretty well any >>>> language (modulo pathologies like COBOL's inability to do dynamic memory >>>> allocation). >>>> >>>> ---------------------------------------------------------------------- >>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>> send email to [email protected] with the message: INFO IBM-MAIN >>>> >>> >>> >>> >>> -- >>> zMan -- "I've got a mainframe and I'm not afraid to use it" >>> >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to [email protected] with the message: INFO IBM-MAIN >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> > > > > -- > zMan -- "I've got a mainframe and I'm not afraid to use it" > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
