From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5c8024b730bb1bfb X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-11-05 14:15:26 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!paloalto-snf1.gtei.net!crtntx1-snh1.gtei.net!nycmny1-snh1.gtei.net!washdc3-snf1!news.gtei.net!cyclone1.gnilink.net!spamfinder.gnilink.net!nwrddc02.gnilink.net.POSTED!53ab2750!not-for-mail From: "Frank J. Lhota" Newsgroups: comp.lang.ada References: <445cd6bf.0211040705.3b638858@posting.google.com> <445cd6bf.0211041157.1537dfd5@posting.google.com> <3DC6DCC4.60301@worldnet.att.net> Subject: Re: Compiler error: 'Expect procedure name in procedure call' X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: <3qXx9.22224$t1.12313@nwrddc02.gnilink.net> Date: Tue, 05 Nov 2002 22:15:27 GMT NNTP-Posting-Host: 141.157.179.11 X-Complaints-To: abuse@verizon.net X-Trace: nwrddc02.gnilink.net 1036534527 141.157.179.11 (Tue, 05 Nov 2002 17:15:27 EST) NNTP-Posting-Date: Tue, 05 Nov 2002 17:15:27 EST Xref: archiver1.google.com comp.lang.ada:30404 Date: 2002-11-05T22:15:27+00:00 List-Id: "Stephen Leake" wrote in message news:usmyhrqkk.fsf@gsfc.nasa.gov... > For most C functions, I agree with this. However, for the specific > case of Win32 C functions, many have a return value which is _defined_ > to be "TRUE", and many others have no documentation on what the return > value might be. This is a side effect of the C compilers letting you > ignore return values; the Win32 authors apparently said something like > "Well, this return value is pretty meaningless, but people can always > ignore it, and we have a coding standard that says 'return a value'" > :). Actually, most Win32 functions have the return type BOOL, a signed 32 bit integer type. The Win32 header define two BOOL constants, FALSE (0) and TRUE (1). The Win32 convention is that these functions with BOOL return values will return FALSE if the function call failed. Now conversely, you would think that these functions would return TRUE when they succeed, but unfortunately this is not the case. Many Win32 functions will sometimes return non-zero BOOL values other than TRUE to indicate success. This is one of the more annoying Win32 "got-chas". One consequence of this "got-cha" is that, independent of which language you are programming in, NEVER do error checking by comparing a Win32 function return value to TRUE. Another Win32 "got-cha" occurs with the Win32 functions that return a HANDLE. Some of these functions indicate an error by returning INVALID_HANDLE_VALUE (-1), while others will indicate an error by returning a NULL (0) handle. Apparently there was a paradigm shift in the middle of the design of the Win32 API, but this inconsistency does create confusion for the legions of Win32 programmer. And don't get me started on the WinSock API, the quirky Win32 adaptation of Berkeley sockets that manages to be annoyingly inconsistent with either POSIX standards or with the rest of the Win32 API.