[PATCH] Fix up discard-const warnings in s4 and tries to remove "discard_const_p"s/"CONST DISCARD"s in both s3 and s4

[Matthias Dieter Wallnöfer]

Hi abartlet,

> This should give you an idea of the scale of the change you are
> proposing.
 
Yeah, I discovered how big they are.

> This is a well trodden path, one that I started on similarly when I
> joined the team.  We don't add these warnings just for fun - they have
> been allowed to persist in the codebase because they are hard to fix
> properly. 
 
Sure.

> In particular, our habit of passing around structures that contain a
> pointer and a length is very hard to make properly const-safe.  Heimdal
> does this in parts by having two structures, one for 'const' principals
> and one for 'non const'.  Then you can have a function that casts
> those. 

> We have not decided to go down that road for DATA_BLOB and TDB_DATA,
> which makes this difficult. 
 
Well, understood. Would make thinks unnecessarely complex.

> (Also, your proposed fixes for Heimdal should be forwarded directly to
> the heimdal-bugs alias, because I'm unwilling to diverage our branch of
> Heimdal for compiler warnings.  See www.h5l.org.  We will eventually get
> them when I resync). 
 
Already spoke with Love. Will do later today.

> > I think a some of the changes are not needed and some introduce real
> > bugs, e.g. the talloc_strdup() for the uint8_t buffers in the
> > gensec_gssapi and schannel_sign code.
> >   
> Where exactly lies the problem here? Memory? (So I can understand the 
> problem)
 
> If the buffer isn't a NULL terminated string (say perhaps it's just
> memory), then a talloc_strdup() could duplicate only part of the
> structure. 

It would be very nice abartlet or also others, if you could tell me exactly the places (files or whole directories) where I should take care of this (so I remove those files from my patch). Since I as a more recent developer here haven't the experience to know about.

> I commend your efforts in trying to reduce the warnings here, but I
> still think there is a long way to go. 
 
Yeah, I set-up exactly for this an own branch so this doesn't bother the normal development.

> As I said on IRC, please produce patches in 3 groups (and split them up
> into per-file patches)
>   - ones that only fix prototypes
>   - ones that adds more const
>   - ones that add talloc calls
 
Yeah I created two commits now for s4. The not-const related warnings are one patch (I think it could be applied - nothing very special if you look at it: I removed some unused variables, fixed includes, fixed a header...) and the other is the const-related (where I/we need to work on).

> Fixing this well is harder than it looks, so please be patient.  Indeed,
> many of the changes may not be ever be merged. 
 
I see

Matthias