Skip to Content.
Sympa Menu

freetds - const

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Castellano, Nicholas" <Nicholas_Castellano AT acml.com>
  • To: "'freetds AT franklin.oit.unc.edu'" <freetds AT franklin.metalab.unc.edu>
  • Subject: const
  • Date: Mon, 4 Nov 2002 15:05:16 -0500


I have just completed several passes over the FreeTDS code base, making much
more widespread use of "const" to indicate data items which should be
considered read-only.

This was useful because it helped located one serious bug
(tds_money_to_string was permanently altering its money input parameter) and
several smaller problems.

I have restricted myself to changing only "internal" interfaces to use
const. I would like to continue this effort and include exposed portions of
our API. For example, I would like to change
RETCODE dbcmd(DBPROCESS *dbproc, char *cmdstring);
to
RETCODE dbcmd(DBPROCESS *dbproc, const char *cmdstring);
because dbcmd does not (and should not) alter the cmdstring argument.

There is no real technical reason not to do this. However, there is one
aesthetic argument against it: Sybase does not use "const" in their
prototypes for these functions.

The real advantage is that it might help spot more bugs in FreeTDS and in
user code calling it, with the help of compiler warnings.

Does anyone object to this change?

Cheers,
--nick


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.





  • const, Castellano, Nicholas, 11/04/2002
    • <Possible follow-up(s)>
    • Re: const, Frediano Ziglio, 11/04/2002
    • Re: const, Castellano, Nicholas, 11/04/2002
    • Re: const, Frediano Ziglio, 11/05/2002

Archive powered by MHonArc 2.6.24.

Top of Page