Compiler error: 'Expect procedure name in procedure call'

Compiler error: 'Expect procedure name in procedure call'

[Jon]

I'm using the GCC compiler, and I'm getting the error 'Expect
procedure name in procedure call'.
Anyone tell me what the heck this means?

Cheers
Jon

Re: Compiler error: 'Expect procedure name in procedure call'

[Stephen Leake]

j_del_strother@hotmail.com (Jon) writes:

> I'm using the GCC compiler, and I'm getting the error 'Expect
> procedure name in procedure call'.
> Anyone tell me what the heck this means?

Probably exactly what it says; the compiler thinks you are making a
procedure call, so it is expecting a procedure name. Instead, you've
given it something else; a variable, package, or function name (to
name just a few of the possibilities). Or maybe you didn't mean to
make a procedure call, and you've got the wrong syntax.

Post the code to get more help.

-- 
-- Stephe

Re: Compiler error: 'Expect procedure name in procedure call'

[Jon]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:<usmyhtkji.fsf@gsfc.nasa.gov>...
> j_del_strother@hotmail.com (Jon) writes:
> 
> > I'm using the GCC compiler, and I'm getting the error 'Expect
> > procedure name in procedure call'.
> > Anyone tell me what the heck this means?
> 
> Probably exactly what it says; the compiler thinks you are making a
> procedure call, so it is expecting a procedure name. Instead, you've
> given it something else; a variable, package, or function name (to
> name just a few of the possibilities). Or maybe you didn't mean to
> make a procedure call, and you've got the wrong syntax.
> 

Ahhh...OK, that makes more sense.  IMO, the error is badly worded...

I was calling a function without using it to assign to a value.

Which leads on to my next question...
Can you call a function & ignore its return value?  I'm using a lot of
Win32 calls, all of which are written as functions rather than
procedures, and I'm getting a huge mess of useless temporary variables
just to allow me to call the functions.

Re: Compiler error: 'Expect procedure name in procedure call'

[Björn Lundin]

Jon wrote:

> Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
> news:<usmyhtkji.fsf@gsfc.nasa.gov>...
>> j_del_strother@hotmail.com (Jon) writes:

> Which leads on to my next question...
> Can you call a function & ignore its return value?  I'm using a lot of
> Win32 calls, all of which are written as functions rather than
> procedures, and I'm getting a huge mess of useless temporary variables
> just to allow me to call the functions.

Import them as procedures instead :)

  pragma Import(C, My_Ada_Procedure, My_C_Function);

in gnat you could use a pragma called something like
 Import_Valued_Procedure

/Bj�rn

Re: Compiler error: 'Expect procedure name in procedure call'

[Jim Rogers]

Jon wrote:

> Which leads on to my next question...
> Can you call a function & ignore its return value?  I'm using a lot of
> Win32 calls, all of which are written as functions rather than
> procedures, and I'm getting a huge mess of useless temporary variables
> just to allow me to call the functions.
> 

Ada does not allow you to ignore return values. Ignoring return
values is a common (but harmful) practice in C. If ignore the
return value the compiler is assuming that you are trying to call a
procedure with the same name as the function you think you are calling.
The error message then becomes an explanation that the compiler cannot
find the a procedure with the name you specified.

You are actually calling C functions. It is still a bad idea to
ignore a return value. The return value is your only indication of an
error from a C function. Ignoring errors is a BAD idea.

Jim Rogers

Re: Compiler error: 'Expect procedure name in procedure call'

[Björn Lundin]

Bj�rn Lundin wrote:

> Jon wrote:
> 
>> Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
>> news:<usmyhtkji.fsf@gsfc.nasa.gov>...
>>> j_del_strother@hotmail.com (Jon) writes:
> 
>> Which leads on to my next question...
>> Can you call a function & ignore its return value?  I'm using a lot of
>> Win32 calls, all of which are written as functions rather than
>> procedures, and I'm getting a huge mess of useless temporary variables
>> just to allow me to call the functions.
> 
> Import them as procedures instead :)
> 
>   pragma Import(C, My_Ada_Procedure, My_C_Function);
> 
> in gnat you could use a pragma called something like
>  Import_Valued_Procedure
> 
> /Bj�rn
Should have added that return values are there for a reason,
it's not a good idea to ignore the result...
/Bj�rn

Re: Compiler error: 'Expect procedure name in procedure call'

[Stephen Leake]

Jim Rogers <jimmaureenrogers@worldnet.att.net> writes:

> You are actually calling C functions. It is still a bad idea to
> ignore a return value. The return value is your only indication of an
> error from a C function. Ignoring errors is a BAD idea.

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'"
:). 

So in some cases, if you have documentation and testing to back it up,
you _should_ ignore return values.

-- 
-- Stephe

Re: Compiler error: 'Expect procedure name in procedure call'

[Vinzent Hoefler]

j_del_strother@hotmail.com (Jon) wrote:

>Which leads on to my next question...
>Can you call a function & ignore its return value?  I'm using a lot of
>Win32 calls, all of which are written as functions rather than
>procedures, and I'm getting a huge mess of useless temporary variables
>just to allow me to call the functions.

Are you *sure*, you won't have to check the function result?

Perhaps you could use a declare block around the "function" call with
a local variable to store the result. The optimizer should be easily
able to remove this reference.


Vinzent.

Re: Compiler error: 'Expect procedure name in procedure call'

[Jon]

Vinzent Hoefler <JeLlyFish.software@gmx.net> wrote in message news:<3dc6e966_1@news.bluewin.ch>...
> j_del_strother@hotmail.com (Jon) wrote:
> 
> >Which leads on to my next question...
> >Can you call a function & ignore its return value?  I'm using a lot of
> >Win32 calls, all of which are written as functions rather than
> >procedures, and I'm getting a huge mess of useless temporary variables
> >just to allow me to call the functions.
> 
> Are you *sure*, you won't have to check the function result?
> 

In some cases, absolutely.  For example, flipping a bitmap to the DC
will return the old bitmap that was originally stored there.  I then
have to create a useless temporary variable for it...

> Perhaps you could use a declare block around the "function" call with
> a local variable to store the result. The optimizer should be easily
> able to remove this reference.
> 

Sure, but it gets very messy when you're calling several dozen C
functions.



Thanks for the help guys, I'll look into the pragma stuff.

Re: Compiler error: 'Expect procedure name in procedure call'

[Dale Stanbrough]

In article <445cd6bf.0211050129.3afa4d54@posting.google.com>,
 j_del_strother@hotmail.com (Jon) wrote:

> 
> In some cases, absolutely.  For example, flipping a bitmap to the DC
> will return the old bitmap that was originally stored there.  I then
> have to create a useless temporary variable for it...


The solution is to create a procedural version of the C function
which assigns the return value to an ignored local variable.

Because you can overload subprograms by return type, you can have
both of them in the same package.

Dale

Re: Compiler error: 'Expect procedure name in procedure call'

[Ted Dennison]

j_del_strother@hotmail.com (Jon) wrote in message news:<445cd6bf.0211041157.1537dfd5@posting.google.com>...
> Which leads on to my next question...
> Can you call a function & ignore its return value?  I'm using a lot of

No. Well...to be precise you can't ignore the return value until after
you have done something with it.

> Win32 calls, all of which are written as functions rather than
> procedures, and I'm getting a huge mess of useless temporary variables
> just to allow me to call the functions.

What I always do for OS calls is wrap them in an Ada routine that
raises an execption for bad statuses. While I'm at it, I convert
between Ada strings and C strings, turn C 0/null defaults into Ada
procedure overloads, etc.

Re: Compiler error: 'Expect procedure name in procedure call'

[Programmer Dude]

Jim Rogers wrote:

> You are actually calling C functions. It is still a bad idea to
> ignore a return value. The return value is your only indication of an
> error from a C function. Ignoring errors is a BAD idea.

But what about C functions in the str* family?  They often just return
their first argument (that is, not an error code).

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|



Opinions expressed herein are my own and may not represent those of my employer.

Re: Compiler error: 'Expect procedure name in procedure call'

[Frank J. Lhota]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> 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 <windef.h> 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.

Re: Compiler error: 'Expect procedure name in procedure call'

[Ted Dennison]

cjsonnack@mmm.com (Programmer Dude) wrote in message news:<3DC82F56.A723BACA@mmm.com>...
> Jim Rogers wrote:
> 
> > You are actually calling C functions. It is still a bad idea to
> > ignore a return value. The return value is your only indication of an
> > error from a C function. Ignoring errors is a BAD idea.
> 
> But what about C functions in the str* family?  They often just return
> their first argument (that is, not an error code).

You're right. C functions have all sorts of different bizzare ways of
returning results and statuses. That's why I generally advocate
isolating interfacing C pragmas in package bodies, with the specs
exporting a cleaned-up Ada interface (removing useless parameters and
returns, raising exceptions for errors, converting ugly C types to
nice clean Ada types, etc.)

Re: Compiler error: 'Expect procedure name in procedure call'

[Randy Brukardt]

Jon wrote in message
<445cd6bf.0211050129.3afa4d54@posting.google.com>...
>Vinzent Hoefler <JeLlyFish.software@gmx.net> wrote in message
news:<3dc6e966_1@news.bluewin.ch>...
>> j_del_strother@hotmail.com (Jon) wrote:
>>
>> >Which leads on to my next question...
>> >Can you call a function & ignore its return value?  I'm using a lot
of
>> >Win32 calls, all of which are written as functions rather than
>> >procedures, and I'm getting a huge mess of useless temporary
variables
>> >just to allow me to call the functions.
>>
>> Are you *sure*, you won't have to check the function result?
>
>In some cases, absolutely.  For example, flipping a bitmap to the DC
>will return the old bitmap that was originally stored there.  I then
>have to create a useless temporary variable for it...
>
>> Perhaps you could use a declare block around the "function" call with
>> a local variable to store the result. The optimizer should be easily
>> able to remove this reference.
>>
>
>Sure, but it gets very messy when you're calling several dozen C
>functions.


If you're doing any significant amount of GUI programming, you are much
better off not calling Win32 at all. Especially because the return codes
are inconsistent (and don't always match the documentation, either.) Use
one of the thick bindings like Claw (www.rrsoftware.com), or even
something platform independent like GtkAda. In the case of bitmap
manipulations, Claw has all of that support built-in and tested. Why
re-invent the wheel??

             Randy.