× 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.



Funny enough, I read an article yesterday that talks about c programmer
should try to avoid using typedef.

The reason that I use typedef is because the moduleName and locationID
should actually be a fix 10 char long variables. The logMessage should
actually be a varying length field of 2048 char long. So, to force all
caller to obey this rule, I used typedef and this was what it looked
like originally:
typedef struct {
char value[10];
} logECD_STP3_piModuleName_T;

typedef struct {
char value[32766];
} logECD_STP3_piLocationID_T;

typedef struct {
unsigned short l;
char a[2048];
} logECD_STP3_piLogMessage_T


But I soon found out that c doesn't allow passing literal to a char
array parameter (<= Not programmer friendly). So I change it to use
char * and left the typedef (lazy me).


-----Original Message-----
From: c400-l-bounces+lim.hock-chai=usamobility.com@xxxxxxxxxxxx
[mailto:c400-l-bounces+lim.hock-chai=usamobility.com@xxxxxxxxxxxx] On
Behalf Of Jevgeni Astanovski
Sent: Friday, June 13, 2008 9:00 AM
To: 'C programming iSeries / AS400'
Subject: Re: [C400-L] Basic c question again - type casting

C is very user friendly. Simply keep it simple.

Why cannot you write:

decimal(15,0) logECD_STP3(char *moduleName, char *locationID, char
*logMessage, const int *byteRcv, const char *dataRcv)

which is exactly the same as yours, but without all these typedefs.
Doesn't it look more simple and readable?

I know nothing about RPG, but from what I read there in your letter, it
seems, that byteRcv must not be passed as pointer but rather as
value....

Jevgeni.


-----Original Message-----
From:
c400-l-bounces+jevgeni.astanovski=sampopank.ee@xxxxxxxxxxxx
[mailto:c400-l-bounces+jevgeni.astanovski=sampopank.ee@midrang
e.com]On Behalf Of Lim Hock-Chai
Sent: Friday, June 13, 2008 4:49 PM
To: C programming iSeries / AS400
Subject: Re: [C400-L] Basic c question again - type casting


Thanks Barbara. I simplified my function to make it easier for me to
ask the question. The actual function prototype looks like below:

typedef char *logECD_STP3_piModuleName_T; typedef char
*logECD_STP3_piLocationID_T; typedef char *logECD_STP3_piLogMessage_T;
typedef int logECD_STP3_piByteRcv_T;
typedef char *logECD_STP3_piDataRcv_T;
decimal(15,0) logECD_STP3(
logECD_STP3_piModuleName_T moduleName,
logECD_STP3_piLocationID_T locationID,
logECD_STP3_piLogMessage_T logMessage,
const logECD_STP3_piByteRcv_T *byteRcv,
const logECD_STP3_piDataRcv_T *dataRcv);

logECDSTP3 is actually a RPG export procedure and the RPG prototype
for
logECD_STP3 looks like below:
P logECD_STP3...
P B export
D pi 15 0
D piModuleName * options(*string) value

D piLocationID * options(*string) value

D piLogMessage * options(*string) value

D piByteRcv 10i 0 options(*nopass :*omit) const

D piDataRcv * options(*nopass :*omit)
D const


The c program is casting the UAM (<= Data from recv()) and passing it
to the 5th parameter of logECD_STP3. The 4th parameter tell
logECD_STP3 how long the 5th parameter is.



c is really fun. It is not very programmer friendly language though.
Not sure how this language can be so successful till this day. :)

-----Original Message-----
From: c400-l-bounces+lim.hock-chai=usamobility.com@xxxxxxxxxxxx
[mailto:c400-l-bounces+lim.hock-chai=usamobility.com@xxxxxxxxxxxx] On
Behalf Of Barbara Morris
Sent: Thursday, June 12, 2008 6:52 PM
To: C400-L@xxxxxxxxxxxx
Subject: Re: [C400-L] Basic c question again - type casting

Lim Hock-Chai wrote:
...
I did below and it compile. Not sure if it will run
correctly or not.
But at least it compiled :)
...
UAM * data;
logECD_STP((char **) &data);


As a general rule, you should aim to code without any casts.
Sometimes
they are necessary, but you should do everything you can to avoid
them.

As a hard-and-fast rule: Never code a cast unless you understand
_completely_ what the effect will be. You have to understand exactly
what the cast means in terms of the layout of storage it is
describing, and you have to understand exactly what is the actual
storage that you are casting. Only then can you assess whether the
cast is valid.

Casting is basically a way to lie to the compiler, and that is A Bad
Thing to do. (I see that Marty already made this point, but I'm
re-making it anyways)

You are telling the compiler that your variable "data" is a "pointer
to character", but it is really a "pointer to UAM". Since you are
only passing 1 parameter to logECD_STP(), it is likely that the
function is treating the parameter as null-terminated string. It is
equally _unlikely_ that your variable "data" actually is a
null-terminated string.

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

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


--
This is the C programming iSeries / AS400 (C400-L) mailing list To post
a message email: C400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/c400-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.