[openssl-project] constification on already released branches

[Tim Hudson]

https://github.com/openssl/openssl/pull/2181
and
https://github.com/openssl/openssl/pull/1603#issuecomment-248649700

One thing that should be noted is that if you are building with -Wall
-Werror (which many projects do) and you are using OpenSSL and things
change from a const perspective builds break - and that then ends up people
having to change code on released versions.

Adding or removing const changes the API. It doesn't technically change the
ABI - although it can impact things as compilers can and do warn for simple
const violations in some circumstances. The straight forward "fix" of a
cast on call actually doesn't achieve anything useful - in that it simply
masks the underlying issue where const was added for a reason.

We should have a clear policy on doing this sort of thing in released code
- either it is okay to do and we should accept patches - or it should never
actually be done. I don't see this as a case-by-case basis for
determination at all - basically it is a single type of API change we
either should be allowing or disallowing.

There is a similar type of API change which is adding typedefs in for
callbacks - which technically also don't change the ABI - and if we allow
any form of API change that also could be considered.

We should discuss this separate from any specific PR and vote to set a
policy one way or the other in my view.

Tim.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] cppflags, cflags and ldflags

[Andy Polyakov]

>> Note: this mail follows the discussion on github started here:
>> https://github.com/openssl/openssl/pull/5742#discussion_r176919954

In the light of the new evidence presented in
https://github.com/openssl/openssl/pull/5745 one can argue in favour of
splitting -pthread flag to cppflags and ldflags. Yes, but I'd still be
reluctant to formulating it like that. As implied I'm kind of arguing
against too many options/variables/joints and call rather for
simplification than increased complexity. I feel that there are more
efficient ways to cover corner/odd-ball places...
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] rule-based building attributes (Re: cppflags, cflags and ldflags)

[Richard Levitte]

Branching a specific thread around these ideas.

In message  on Sun, 25 Mar 
2018 18:45:40 +0200, Andy Polyakov  said:

appro> > Another side thing that I've been thinking of for quite a while, and I
appro> > think you may have argued for even though I feel a bit unsure, and
appro> > that's to support command line attributes as an alternative to that
appro> > increasing amount of specialised attributes, so something like this:
appro> > 
appro> >link => '$(CCLD) $(LDFLAGS) -o $@ ...',
appro> 
appro> You've mentioned once that it would take a special language to do that
appro> something, and I recall myself thinking "why not just use make syntax".
appro> I'm unsure if I actually said this, but I did think the thought. So that
appro> I for one wouldn't actually be opposed to something like this. It's just
appro> a way to specify "override" rule (and on per-toolchain basis:-).
appro> However! It all depends on whether or not straight make syntax would
appro> actually be expressive enough in the context. If it is, then it would be
appro> totally appropriate. But if not, then ... I'm not so sure. Maybe[!]
appro> if-else in makefile template could turn out to be more appropriate.
appro> (Once again, each clause in if-else is isolated and complexity is
appro> linearly proportional to number of clauses in if-else, which is viewed
appro> as advantage.)

Straight make syntax will probably not cut it.  How would you pass a
list of object file names to something that might have a limited
command line length, for example?  With nmake, we do have a feature we
can use, the inline file text thing, but others may not be so lucky
(the nonstop case I mentioned is such a case), and one might need to
do a bit of pre-processing with perl-level variables (an idea could be
to have some well defined hooks that users can define values for, such
as function names...  again, this is a draft of an idea).  For
example, imagine that we have something that dumps object file names
into a text file and then expects that file name to appear in the
linking command line (for example, and typically in our case), how do
we pass the text file name to the command line, and where in the
command line?

So no, a straight makefile rule for a config attribute value isn't
going to be good enough.


Coming back to costs, I would think that this direction might actually
reduce it for us as it avoids all those gazillion specialized
attributes (I've grown to dislike them too, FYI), and at the same time
become general enough to help users who want to use our stuff for
their own oddball platform to do so, with our blessing...  and I hope
that it helps us as well.

But, this line of ideas is a major change in the how the config
targets work (although I can see a smooth transition from one to the
other, so it's not like we *have* to wait until OpenSSL 1.2 to
implement it), and it is some work to get through with it.  I see
enough benefits to want to, though, and am currently in the mood of
bouncing ideas as time permits (*).

Cheers,
Richard

(*) no, I haven't forgotten that we have a primary focus in fixing
stuff that needs fixing before the final 1.1.1 release.  But it's
Sunday right now, tomorrow will be more focused.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] cppflags, cflags and ldflags

[Richard Levitte]

Note: this mail follows the discussion on github started here:
https://github.com/openssl/openssl/pull/5742#discussion_r176919954
That discussion started as a simple side note, but I should probably
have known better...  it ends up derailing a PR that shouldn't really
be affected, so I'm bringing the discussion here.

The discussion is about the division of flags for the different parts
of building programs, shared libraries and DSOs.

So we have one side that argues for putting the majority of the flags
in the cflags variable / config attribute.  To quote from the github
discussion:

> Or to put a little bit more practical spin on it. Since we *do* pass
> cflags at *all* stages, it's only appropriate to assign multi-stage
> flags [such as -pthread] to cflags. Viewing it from another angle,
> only pure single-stage flags [such as -L ,-l, -I, -D] are
> appropriate to separate as make variables. And to variables specific
> to corresponding stage, not some other grouping. Last remark is
> reference to the fact and if one follows suggested logic [that
> presented classification imposes specific separation as make
> variables], you'd have to pass -L at pre-processor stage and -I at
> linker, because they both are listed in "Directory Options".

My spin on it goes in a different direction.  It's true that we
*currently* pass cflags to all stages.  I would argue, though, that
this is mostly because we assume that the cc command is an appropriate
frontend for everything involving building the stuff.  Enters the odd
ball that needs to use the linker (som form of ld) directly [1],
because that's what makes practical sense, or simply because that's
how things work on that platform, and suddenly, it's obviously
*inappropriate* to pass cflags on that command.  In assuming that we
can always pass cflags, we're making live difficult for those who want
to make things work on platforms that don't quite meet that assumption.

So following my spin, I would rather say that any flag that affects
preprocessing should go into cppflags, any flag that affects linking
should go into ldflags (the attribute lflags), the rest can go to
cflags.  And for compartmentalization, I'd like to see that:

- for preprocessing, only cppflags are used.  (note: this is more of a
  wishlist, not really terribly important for now...)
- for compiling (i.e. source code to object code), cppflags and cflags
  are used (I cannot see how one would make that differently).
- for linking, only ldflags should be used.  (this I think is
  important!)


[1] Just in case you wonder, there is a use case for using the linker
directly instead of using cc as a frontend:
https://github.com/openssl/openssl/issues/5087

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] constification on already released branches

[Richard Levitte]

In message  
on Mon, 26 Mar 2018 08:36:17 +1000, Tim Hudson  said:

tjh> https://github.com/openssl/openssl/pull/2181
tjh> and
tjh> https://github.com/openssl/openssl/pull/1603#issuecomment-248649700
tjh> 
tjh> One thing that should be noted is that if you are building with
tjh> -Wall -Werror (which many projects do) and you are using OpenSSL
tjh> and things change from a const perspective builds break - and
tjh> that then ends up people having to change code on released
tjh> versions.
tjh> 
tjh> Adding or removing const changes the API.

I would like to point out that we're looking at two different const
changes, and the distinction *is* important.

One constification is changing the constness of a function's input
parameter.
Another constification is changing a function's return type.

The impact of these two types of constification is very different (I
would say "obviously", but I might be wrong, it might not be obvious
to everyone), and they should be regarded different, not piled
together in one "we do / do not allow constification in released
branches".  I'm going to argue that even though there are cases where
one type of constification affects the other (such as constifying an
input parameter might force a constification of the return type), they
can still be looked at individually, and policy can be made on them
individually.

tjh> We should have a clear policy on doing this sort of thing in
tjh> released code - either it is okay to do and we should accept
tjh> patches - or it should never actually be done. I don't see this
tjh> as a case-by-case basis for determination at all - basically it
tjh> is a single type of API change we either should be allowing or
tjh> disallowing.

(a reminder: we're talking about *two* types of API changes that both
involve 'const', not a single API change).

I agree.  We currently have a kinda sorta policy that's quite vaguely
formulated in the FAQ (https://www.openssl.org/docs/faq.html#MISC7),
and we do have something formulated in the release strategy
(https://www.openssl.org/policies/releasestrat.html) as well.  I'll
note that none of them says "the API must not change".  As a matter of
fact, the release strategy only mentions binary compatibility (i.e.
talks exclusively about ABI compatibility).  The FAQ does mention
source (i.e. API) compatibility, formulated as an implication:

   Changes to the middle number are considered major releases and
   neither source nor binary compatibility is guaranteed.

This implies that we do guarantee source and binary compatibility.
What that means exactly is left for us to discuss and decide upon.
I would like to suggest that there should be a document where we
collect what we think "compatibility" means, i.e. what we allow and
disallow ourselves to do.  Kind of a declaration of intention, if you
will.  This should be a document that can be edited over time (but
with great care), and such changes should be voted on, of course.

tjh> There is a similar type of API change which is adding typedefs in
tjh> for callbacks - which technically also don't change the ABI - and
tjh> if we allow any form of API change that also could be
tjh> considered.
tjh> 
tjh> We should discuss this separate from any specific PR and vote to
tjh> set a policy one way or the other in my view.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project