Re: [Cscope-devel] (no subject)

[Petr S. <pe...@sc...>]

Hi Hans,

My issue was with conflicting ANSI C documentation and a difference of
opinion between ANSI members which I'm in contact with. The issues have
been resolved, and its ok. So go ahead, but remember that the there is a
4pm EST cutoff today. So if you can't get the changes in by then, rather
have them done for bl3.

Petr
> After having worked on cscope as an outsider, for a while, Petr
> has added me in as a developer. I'd like to present some questions
> to y'all, regarding next steps I'ld like to make.
> 
> Of my patches offered so far, Petr mainly refused one kind: pointer casts
> with malloc() and friends, or their cscope-internal wrappers, mymalloc()
> and friends. Going with the C FAQ recommendations, I'ld like to get rid of
> all these casts. They serve no useful purpose in an ANSI C compiled
> program, for a start, but they tend to clutter the source code. They may
> even hide actual bugs if no proper prototype for the relevant function is
> visible to the compiler. To quote the comp.lang.c FAQ explanation of this:
> 
> --- snip ---
> 7.7:    Why does some code carefully cast the values returned by malloc
>         to the pointer type being allocated?
> 
> A:      Before ANSI/ISO Standard C introduced the void * generic pointer
>         type, these casts were typically required to silence warnings
>         (and perhaps induce conversions) when assigning between
>         incompatible pointer types.
> 
>         Under ANSI/ISO Standard C, these casts are no longer necessary,
>         and in fact modern practice discourages them, since they can
>         camouflage important warnings which would otherwise be generated
>         if malloc() happened not to be declared correctly; see question
>         7.6 above.  (However, the casts are typically seen in C code
>         which for one reason or another is intended to be compatible
>         with C++, where explicit casts from void * are required.)
> --- snip ---
> 
> I.e.: unless we want to make cscope a C++ program, in the near future, we
> might better get rid of those casts.
> 
> Hans-Bernhard Broeker (br...@ph...)
> Even if all the snow were burnt, ashes would remain.
> 
> _______________________________________________
> Cscope-devel mailing list
> Csc...@li...
> http://lists.sourceforge.net/mailman/listinfo/cscope-devel

-- 
--------------------------------------------------------
Petr Sorfa                  Software Engineer
Santa Cruz Operation (SCO) 
430 Mountain Ave.           http://www.sco.com
Murray Hill 07974
NJ, USA
--------------------------------------------------------
Disclaimer: All my comments are my own and nobody else's
----------------------------------------------------------