Skip to Content.
Sympa Menu

freetds - RE: [freetds] too many casts, sire

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Thompson, Bill D (London)" <bill_d_thompson AT ml.com>
  • To: "'FreeTDS Development Group'" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] too many casts, sire
  • Date: Tue, 13 Apr 2004 14:04:05 +0100

Jim,

I recognise my own code when I see it!
I taught myself C on an IBM RT PC 6150 (anyone else remember those ?) some
17 years ago.
Maybe on that first version of AIX, it was necessary to cast like that.
I'll endeavour to bring myself into the 21st century though...perhaps one
day I'll even learn C++ ....

Bill

> -----Original Message-----
> From: James K. Lowden [SMTP:jklowden AT schemamania.org]
> Sent: 07 April 2004 04:16
> To: TDS Development Group
> Subject: [freetds] too many casts, sire
>
> http://www.fiendish.demon.co.uk/c/casting.html
> http://www.vmunix.com/~gabor/c/draft.html#6.2.2.3
>
> I came across this line in bcp.c (reformatted):
>
> if ((curptr->nextptr =
> (struct fflist *) malloc(sizeof(struct fflist)))
> == (struct fflist *) NULL)
>
> ANSI C says:
>
> 1. It's never necessary to cast to compare to a null pointer.
> 2. It's never necessary to cast void* for assignment.
>
> That tells me this could as well read:
>
> if ((curptr->nextptr =
> malloc(sizeof(struct fflist))) == NULL)
>
> which I can actually read. Is there any reason not to simplify this? Is
> anyone really using a malloc() that returns char* in 2004? (The casting
> of NULL is just plain egregious, not merely old fashioned.)
>
> --jkl
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds

==============================================================================

If you are not an intended recipient of this e-mail, please notify
the sender, delete it and do not read, act upon, print, disclose,
copy, retain or redistribute it.

Click here for important additional terms relating to this e-mail.
<http://www.ml.com/email_terms/>

==============================================================================





Archive powered by MHonArc 2.6.24.

Top of Page