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



One more thing.
You write:
memcpy (sfrcd.S01FUNC , " ", 2 );
memcpy (sfrcd.S01APFILE, " ", 10 );
memcpy (sfrcd.S01APLIB , " ", 10 );
memcpy (sfrcd.S01APACCP, " ", 1 );
memcpy (sfrcd.S01APUNIQ, " ", 1 );
memcpy (sfrcd.S01APSELO, " ", 1 );
memcpy (sfrcd.S01APFTYP, " ", 1 );
memcpy (sfrcd.S01APJOIN, " ", 1 );
memcpy (sfrcd.S01APKEYO, " ", 1 );
memcpy (sfrcd.S01APKSEQ, pfrcd.APKSEQ, 1 );
memcpy (sfrcd.S01APKSIN, pfrcd.APKSIN, 1 );
memcpy (sfrcd.S01APKEYF, pfrcd.APKEYF, 10 );

My advise is to do it another way:
memset(&sfrcd, ' ', sizeof(sfrcd)) ;
memcpy (sfrcd.S01APKSEQ, pfrcd.APKSEQ, 1 );
memcpy (sfrcd.S01APKSIN, pfrcd.APKSIN, 1 );
memcpy (sfrcd.S01APKEYF, pfrcd.APKEYF, 10 );

C differs from other languages - it does not initialize variables on declarations in general, and structures - in particular.
So by setting full structure to spaces and then assigning/initializing only specific fields you make your program at least shorter. But also more reliable.
Of course you must take care of numeric fields - you have to explicitly assign valid numeric values to them before accessing.


-----Original Message-----
From: c400-l-bounces@xxxxxxxxxxxx [mailto:c400-l-bounces@xxxxxxxxxxxx] On Behalf Of Frank Kolmann
Sent: Thursday, April 03, 2014 1:39 PM
To: c400-l
Subject: [C400-L] First C program

Hi Jevgeni



Thank you. You make good points.

That is a good way of trapping the == issue.

I will follow Barbaras advice in the coding of the if.



I like the way you use the #define for the type defs.

It does make the code clearer, I will use that sytle.



Frank





*Subject: Re: First C program

*From: Jevgeni Astanovski <Jevgeni.Astanovski@xxxxxxxxxxxxx>

*Date: Wed, 2 Apr 2014 07:54:34 +0000

Yes. Barbara mentioned the define and I haven't...

Definitely there are lots of this sort of advises to avoid =/==
possible
mistake.

I've never saw the one you referred.

However some use another technique:

Instead of writing

if ((pf = _Ropen(PFILENAME, "rr")) == NULL)

they write

if (NULL == (pf = _Ropen(PFILENAME, "rr")))

In this case if you make a mistake and write

if (NULL = (pf = _Ropen(PFILENAME, "rr")))

you will immediately get a syntax error.



....



On the second issue - this is purely a question of how readable is your
program.

My personal practice is to use "explicit" way of defining types. For
example:



#pragma mapinc("dspf", "*LIBL/Y80ALD(ADDCHRG)", "both", "_P", "Y80",
"Y80")

#include "dspf"

#define INPUT_T Y80_ADDCHRG_i_t

#define OUTPUT_T Y80_ADDCHRG_o_t


in this case it is (more) clear where these types are derived from....
--
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (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 ...

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.