This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v5] Add pretty printers for the NPTL lock types


Oddly enough, I'm testing the 'next' command on split lines and it seems to be
working fine. Maybe I had some optimization turned on back when I first tried it.
I'll keep testing it a bit more, perhaps it was an isolated case I'm not currently
seeing.

In any case, if this works I'll just split the lines and keep the scripts mostly
as they are now. Speaking of which, what's the policy for splitting long lines?
For example:

  if (pthread_condattr_setpshared (attr, PTHREAD_PROCESS_SHARED) == 0 /* Set shared.  */
      && condvar_reinit (condvar, attr) == PASS

I understand this should be split like this:

  if (pthread_condattr_setpshared (attr, PTHREAD_PROCESS_SHARED)
      == 0 /* Set shared.  */
      && condvar_reinit (condvar, attr) == PASS

Right? What about lines where both the function and the parameters are so long
that they can't be reasonably split? E.g.

      && pthread_rwlockattr_setkind_np (attr, PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP) == 0
      && rwlock_reinit (rwlock, attr) == PASS)

If I were to split the first line before the operator, it'd still be too long:

      && pthread_rwlockattr_setkind_np (attr, PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP)
      == 0
      && rwlock_reinit (rwlock, attr) == PASS)

Same goes for splitting it between the parameters:

      && pthread_rwlockattr_setkind_np (attr,
                                        PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP) == 0
      && rwlock_reinit (rwlock, attr) == PASS)

Using a macro or inline function just for that one line sounds like overkill to me.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]