Re: [openssl-project] Style guide updates

2018-01-28 Thread Andy Polyakov
> Multiline conditionals, such as in an if, should be broken before the
> logical connector and indented an extra tabstop.  For example:

One can wonder if it would be appropriate to explicitly say that
preferred way to organize multi-line conditionals with same chain
condition per line even if pair of them fit into line. I mean

if (this-is-long
  && that
  && even-that)

vs.

if (this-is-long
  && that && even-that)

with first example being preferred. And this is even if 'this-is-long'
is short.

[Or should one tolerate following provided that 'this' is short enough?

if (this && that
  && even-that)
]

Either way, suggestion is that *if* you find yourself breaking condition
to multiple lines, you should take it step further, if not all the way.
But it shouldn't preclude things like

if (this-is-long
  && (that || (even-that && not-the-one))
  && don't-forget-this)

This actually means that one should be able to write second example as

if (this-is-long
  && (that && even-that))

but it would imply that logical relation between 'that' and 'even-that'
is strong enough to justify the parentheses.


[Also note that in above examples additional indentation is just two
spaces. It's not a coincidence, it's also kind of suggestion, for
if-specific indentation.]
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Style guide updates

2018-01-27 Thread Benjamin Kaduk
On Fri, Jan 26, 2018 at 01:26:58PM +, Salz, Rich wrote:
> Some things I think we should add to the style guide.  Let’s discuss here.
> 
> No space after sizeof, use parens.  (But see ssl/record/rec_layer_{d1,s3}.c )
> 
> Multiline conditionals, such as in an if, should be broken before the logical 
> connector and indented an extra tabstop.  For example:
> 
> while (this_is_true
>   && that_is_not_false) {
> frobit();
> more_stuff();
> }

To state it explictly, in the absence of the "extra" indentation
this would be formatted

while (this_is_true
   && that_is_not_false) {
frobit();
more_stuff();
}

which is, as was noted, quite readable for the while() case, and
only if() has trouble.

> When dealing with long lines, try to avoid breaking across a function call. 
> Don’t do this:
> If (some_long_text && foo(a,
>  b, c) && bar()) {

And for this specific case, I am used to the rule being that if you
break mid-function-call, you indent to the paren for the function
call, as in

if (some_long_text && foo(a,
  b, c) && bar()) {

which rather inherently incentivizes not breaking across the
function call.

I read the rest of the thread and don't really have more to add to
it.

-Ben

> Instead do this:
> If (some_long_text
> && foo(a, b, c,)
> && bar())
> 
> What else needs to be updated?
> 

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

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

Re: [openssl-project] Style guide updates

2018-01-27 Thread Andy Polyakov
>> - Use size_t for sizes of things
> 
> How do you feel about ssize_t?

One has to keep in mind that ssize_t is not part of C language
specification, but POSIX thing. C specification defines ptrdiff_t with
[presumably] desired properties. However, there is natural ambiguity
originating from fact that size_t customarily "covers" twice as much
space. So if you are to rely on positivity of signed value, object has
to be small enough. In other words you would have to perform sanity
checks before you do so. So it's not exactly walk on roses. I mean if
one assumes the premise that signed is "easier" to handle. Well, one can
make all kind of practical arguments about practicality of such
situation, i.e. what it takes to run into ptrdiff_t vs. size_t
ambiguity, and argue that it never happens. Well, while it would be case
on most systems, there are two cases, arguably not that impractical.
64-bit VMS, where we have sizeof(size_t)

Re: [openssl-project] Style guide updates

2018-01-27 Thread Kurt Roeckx
On Sat, Jan 27, 2018 at 01:03:04PM +0100, Kurt Roeckx wrote:
> 
> It's just that there seem to be 2 camps, one saying that all types
> should be signed except when it's to access the bits. The other
> that a size can't be negative so you go for an unsigned type. If
> it's a signed type you could check that they gave you a negative
> value by accident and return an error.

The other argument to go with a signed type it's that it's easier
to write a reverse for loop and not end up with an infite loop.


Kurt

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


Re: [openssl-project] Style guide updates

2018-01-26 Thread Andy Polyakov
> What else needs to be updated?

Relax requirement that argument names in function definition has to
match function declaration to permit adding 'unused_' prefix prior
unused arguments.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Style guide updates

2018-01-26 Thread Andy Polyakov
> - Don't use else after return?

I'd argue against making it an absolute requirement. To give an example.
You don't a problem with returns in switch, so why should it be a
problem with returns from switch-like if-elseif chain?
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Style guide updates

2018-01-26 Thread Matt Caswell


On 26/01/18 17:03, Richard Levitte wrote:
> In message  on Fri, 26 Jan 
> 2018 14:06:27 +, Matt Caswell  said:
> 
> matt> - Use size_t for sizes of things
> 
> ... and, it seems, as array index.
> 

Yes - because an array index is bounded by the size of the array, which
would be defined by a size_t.

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