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