× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



In c, all the parameters are COPIED onto the stack. Everything is passed
by value. Parameters must be c primitives, eg, int, float, double, etc,
or pointer.

The stack is a temporary piece of storage that provies the interface to
the called function. When the called function returns, that peice of
memory is obliterated. (It isn't actually, but it can be used again by
something else that would write right over whatever was there.)

The definition here (the function prototype) is saying that the function
called (iconv) expects this on the stack in this order:
an integer (probably, there's a typedef somewhere that defines
iconv_t)
a pointer to a character array
a pointer to an integer (probably)
a pointer to a character array
a pointer to an integer (probably)

typedefs that resolve to primitives are still primitives.

char * is the same as char [] by definition

character arrays work very well for RPG character variables.

The called function has no idea how long that char array is unless you
tell it. Usually the size_t parameter that follows is the length and
usually it specifies the max length. You set that when you call the
function to the length of the space you've allocated (the length of the
RPG field). The called function may update that value with the actual
number of characters it puts into that char array.

char arrays may be mapped with structs. No matter, it is still a char
array at its lowest level even if it contains integers, pointers or
other stuff.

You really need to look at the typedefs for iconv_t to see what you need
to pass. Most of these are two byte integers (RPG: 10 u 0), but
sometimes you'll run across a 1 byte integer field. More often now we're
seeing 4 byte integers.

So you for iconv should pass
an integer by value
an RPG field (or data structure) by reference
an integer by reference
an RPG field by reference
an integer by reference

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Neill Harper
Sent: Friday, February 05, 2010 4:13 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: iconv query

Ok thanks guys.

I wonder if we could may be close this thread off by commenting on the
following - just to help a youthful (read ignorant) RPG programmer
confirm that he really doesn't understand what is going on with the C
style apis.

Syntax


#include <iconv.h>

size_t iconv (cd, inbuf, inbytesleft,
outbuf, outbytesleft)


iconv_t cd;
char **inbuf;
size_t *inbytesleft;
char **outbuf;
size_t *outbytesleft;

cd = Is passed by value because there is no asterisk in front of it
inbuf = Is passed by reference, i.e. two asterisks means pass a pointer
by reference inbytesleft = Is passed by reference as there is an
asterisk

Neill

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: 05 February 2010 19:41
To: Midrange Systems Technical Discussion
Subject: Re: iconv query

Hello,

I'm confused. With C, when calling a function, all argument
(parameter) passing is is by value. That's how C is defined.

True. By that logic, nothing in C can ever be passed by reference.

However, I don't think it's unreasonable to refer to passing the address
of a variable as "passing by reference". That's the normal way of
passing things by reference in the C language.


So what's wrong with "C-structs are passed that way"? For it not to be

passed "that way" (by value) you need to change what you're passing --

namely to a pointer to the struct.

That's a technicality, Bruce, and you know it -- that's why you refer to
your message as "nit picking".

What's wrong with the original statement of "C-structs ar passed that
way" is that it implies that whenever a C programmer wants to pass a
data structure from one function to another, that they *always* pass it
by value. And that's simply not true. Heck, it's not even true in a
majority of cases.

You almost always see structures passed like this:

struct mydata {
int var1;
char var2[50];
};

int dosomething(struct mydata *arg) {
/* whatever */
}

int main(int argc, char **argv) {
struct mydata x;
if (dosomething(&x)) {
/* whatever */
endif;
return 0;
}

You can say "but, when you pass a pointer, you're not passing the data
structure, you're passing a pointer" but that's just a technicality.
The programmer's intent is to pass a data structure by reference. That's
the *reason* why this is being done, and it's by far the most common
means of passing a data structure in C (at least in my experience).

Vern's post was aimed at an RPG programmer trying to call a function
that was written in C, and documented by IBM using C prototypes and C
examples instead of the more common language-neutral API documentation
format.

The RPG programmer was trying to figure out how to call the function.
And in this case, he *should* pass it by value. But this is not because

"C always passes data structures by value". If you called another
function where it passed the data by address, then you should pass it by
address. Do what the function calls for, and NOT "always by value
because that's the way C does it."
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.