On 23/09/2008, at 9:51 AM, Erick Garske wrote:

I have a nested typedef structure for myEC that contains the variable
portion of the execption data. I've hard coded this at 100, but I have
also seen the Exeption data defined as large as 32767. What is the
best why to define the exception data?

I use 1024. Reasoning is 1K is a nice round number. Rochester's design of the error code structure is flawed because it should have a size of exception data field. This has been corrected if you use format ERRC0200 for the error code structure instead of format ERRC0100. See the Error code parameter section of the Information Centre.

1K has been sufficient for all my use of APIs.

Also, I have made the tyepdef Structure local to both main and
myFunction, so I believe that the compiler should define both
structures local to their functions.

What's the point of defining a typedef twice? It's a user-defined type so define it once globally--preferably in an include-- and just declare instances of it wherever you need it.

Any other comments would be greatly appreciated.

int myFunction(void * pApiErrCd)

should be

int myFunction(myErC_t * pApiErrCd)

otherwise you are lying to the compiler.

If you do that then you won't need this:

myEC_t * ApiErrCd;

and then you won't need this either:

ApiErrCd = pApiErrCd;

The compiler has already passed you a pointer to the structure so just use it via the indirection operator. What is the point of passing void*, declaring another pointer to myEC_t, and assigning the passed pointer to the local pointer?

Simon Coulter.
FlyByNight Software OS/400, i5/OS Technical Specialists

Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
ASCII Ribbon campaign against HTML E-Mail / \

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

This mailing list archive is Copyright 1997-2021 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.