🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c
Article #4907

Re: Prefixing functions with return type..

#4907
From: Adrian P Stephens
Date: Mon, 18 Mar 1996 20:16
81 lines
3767 bytes
[ posted for aps@symbionics.com by steve@Watt.COM ]

To: Steve Watt -- KD6GGD <steve@Watt.COM>
From: Adrian P Stephens <aps@symbionics.co.uk>
Date: Mon, 18 Mar 1996 12:41:43 +0000

(Steve,  please could you post this to comp.std.c for me,  my news out
 feed is broken.  Thankx.)


Steve Watt -- KD6GGD wrote:
> 
> In article <4hstf8$jf3@cybernews.cyberus.ca> robert_mohid@cyberus.ca (Robert Mohid) writes:
> >I've been recently told that the practice of prefixing functions to
> >indicate return type (ie: int iGetInt(void)   ) is "part of a new
> >approach in progrmming". Can anyone confirm/deny this? I am extremely   <<++>>
> >skeptical about that last statement, and to any who would reply
> >*please* include some references as to make your claims as irrefutable
> >as possible.   Thanks in advance.
> 
> Well, it's a slightly newish thing.  Microsoft decided to use it(*) in
> their Windows code.  Many (many many!) people think it makes the names
> much harder to read -- if I wanted to look at names with lots of type
> information in them, I'd look at the output of a C++ translator.

Love them or loath them,  standards are important to any company.  Ours
has "C" coding standards which require this kind of thing.   Initially
I was against it,  because it makes things cluttered,   lengthens lines
of code and makes for more typing.

Our standards also require explicit
identification of the size returned if it is an integer.   This is of 
benefit if you are doing emulation/debugging without a symbolic emulator/
debugger (and how many do that??),   but otherwise doesn't allow you to
pretend you've got "opaque types" in "C".   Also,  for some things where
the type is not selected until compile time (e.g. integer sizes and 
size_t particularly) you cannot select a name which is legal in the
sense of these standards.

Here's an example from a bit of code I'm working on now:

extern TX_MANAGEMENT_PKT * psTxManagementPktTXP_NewTxBeaconPkt(void);

Elements required in our standard:

   TX_MANAGEMENT_PKT  - all upper case because it's a typedef/struct
   p                  - pointer to ...
   sTxManagementPkt   - a structure of this type (but case converted)
   TXP                - name of module containing global export
   "NewTxBeaconPkt"   - What I orginally called the routine before
                      - I read our coding standards.


Oh,  and finally another example from real code:

/*--------------------------------------------------------------------------
 * Routine:     u32GetU32
 *
 * Parameters: Name         r/w     Usage
 *              char **     *w      ppcParams
 *                                  
 * Returns:    u32 value
 *
 * Description:
 *      Read and return a u32 value from the command-line,  reading decimal
 *      numbers by default,  or hex if preceded by "0x".
 *--------------------------------------------------------------------------*/
extern u32 u32GetU32(char ** ppcParams);

Which,  I guess,  answers "<<++>>" above.


> [snip] 

Adrian P Stephens

aps@symbionics.co.uk            Symbionics  Ltd
Tel: +44 1223 421025 (work)     St John's Innovation Park
                                Cowley Road
                                Cambridge CB4 4WS,    UK
---------------------------------------------------------
Technical Details
Message-ID: <1996Mar18.201616.6958@Watt.COM>
Path: arc1-ca.pugleaf.net!in2.uu.net!bast!wattres!steve
References: <4hstf8$jf3@cybernews.cyberus.ca> <1996Mar14.080731.15076@Watt.COM>

Show Full Headers
Complete Article Headers
Newsgroups: comp.std.c
Path: arc1-ca.pugleaf.net!in2.uu.net!bast!wattres!steve
From: Adrian P Stephens <aps@symbionics.co.uk>
Subject: Re: Prefixing functions with return type..
Sender: Steve Watt -- KD6GGD <steve@watt.com>
References: <4hstf8$jf3@cybernews.cyberus.ca> <1996Mar14.080731.15076@Watt.COM>
Organization: Symbionics Ltd
Message-ID: <1996Mar18.201616.6958@Watt.COM>
Date: Mon, 18 Mar 96 20:16:16 GMT