Re: [libvtv] Fix formatting errors

2015-08-26 Thread Jeff Law

On 08/26/2015 01:50 PM, Caroline Tice wrote:

As far as I know vtv is working just fine...is there something I don't
know about?
I'm not aware of anything that isn't working, but I'm also not aware of 
vtv in widespread use, typical performance hit experienced, etc.


jeff



Fwd: [libvtv] Fix formatting errors

2015-08-26 Thread Caroline Tice
-- Forwarded message --
From: Caroline Tice 
Date: Wed, Aug 26, 2015 at 12:50 PM
Subject: Re: [libvtv] Fix formatting errors
To: Jeff Law 
Cc: Rainer Orth , GCC Patches



As far as I know vtv is working just fine...is there something I don't
know about?

-- Caroline
cmt...@google.com

On Wed, Aug 26, 2015 at 12:47 PM, Jeff Law  wrote:
>
> On 08/26/2015 07:30 AM, Rainer Orth wrote:
>>
>> While looking at libvtv for the Solaris port, I noticed all sorts of GNU
>> Coding Standard violations:
>>
>> * ChangeLog entries attributed to the committer instead of the author
>>and with misformatted PR references, entries only giving a vague
>>rational instead of what changed
>>
>> * overlong lines
>>
>> * tons of whitespace errors (though I may be wrong in some cases: C++
>>code might have other rules)
>>
>> * code formatting that seems to have been done to be visually pleasing,
>>completely different from what Emacs does
>>
>> * commented code fragments (#if 0 equivalent)
>>
>> * configure.tgt target list in no recognizable order
>>
>> * the Cygwin/MingW port is done in the worst possible way: tons of
>>target-specific ifdefs instead of feature-specific conditionals or an
>>interface that can wrap both Cygwin and Linux variants of the code
>>
>> The following patch (as yet not even compiled) fixes some of the most
>> glaring errors.  The Solaris port will fix a few of the latter ones.
>>
>> Do you think this is the right direction or did I get something wrong?
>>
>> Thanks.
>>  Rainer
>>
>>
>> 2015-08-26  Rainer Orth  
>>
>> Fix formatting errors.
>
> I'm more interested in the current state of vtv as I keep getting dragged 
> into discussions about what we can/should be doing in the compiler world to 
> close more security stuff.
>
> Vtables are an obvious candidate given we've got vtv.
>
> Jeff


Re: [libvtv] Fix formatting errors

2015-08-26 Thread Jeff Law

On 08/26/2015 07:30 AM, Rainer Orth wrote:

While looking at libvtv for the Solaris port, I noticed all sorts of GNU
Coding Standard violations:

* ChangeLog entries attributed to the committer instead of the author
   and with misformatted PR references, entries only giving a vague
   rational instead of what changed

* overlong lines

* tons of whitespace errors (though I may be wrong in some cases: C++
   code might have other rules)

* code formatting that seems to have been done to be visually pleasing,
   completely different from what Emacs does

* commented code fragments (#if 0 equivalent)

* configure.tgt target list in no recognizable order

* the Cygwin/MingW port is done in the worst possible way: tons of
   target-specific ifdefs instead of feature-specific conditionals or an
   interface that can wrap both Cygwin and Linux variants of the code

The following patch (as yet not even compiled) fixes some of the most
glaring errors.  The Solaris port will fix a few of the latter ones.

Do you think this is the right direction or did I get something wrong?

Thanks.
 Rainer


2015-08-26  Rainer Orth  

Fix formatting errors.
I'm more interested in the current state of vtv as I keep getting 
dragged into discussions about what we can/should be doing in the 
compiler world to close more security stuff.


Vtables are an obvious candidate given we've got vtv.

Jeff


[libvtv] Fix formatting errors

2015-08-26 Thread Rainer Orth
While looking at libvtv for the Solaris port, I noticed all sorts of GNU
Coding Standard violations:

* ChangeLog entries attributed to the committer instead of the author
  and with misformatted PR references, entries only giving a vague
  rational instead of what changed

* overlong lines

* tons of whitespace errors (though I may be wrong in some cases: C++
  code might have other rules)

* code formatting that seems to have been done to be visually pleasing,
  completely different from what Emacs does

* commented code fragments (#if 0 equivalent)

* configure.tgt target list in no recognizable order

* the Cygwin/MingW port is done in the worst possible way: tons of
  target-specific ifdefs instead of feature-specific conditionals or an
  interface that can wrap both Cygwin and Linux variants of the code

The following patch (as yet not even compiled) fixes some of the most
glaring errors.  The Solaris port will fix a few of the latter ones.

Do you think this is the right direction or did I get something wrong?

Thanks.
Rainer


2015-08-26  Rainer Orth  

Fix formatting errors.

# HG changeset patch
# Parent 6459822b8e6fa7647ad0d12ffb6f3da7bd0c5db2
Fix formatting errors

diff --git a/libvtv/ChangeLog b/libvtv/ChangeLog
--- a/libvtv/ChangeLog
+++ b/libvtv/ChangeLog
@@ -1,6 +1,6 @@
-2015-08-01  Caroline Tice  
+2015-08-01  Eric Gallager  
 
-	PR 66521
+	PR bootstrap/66521
 	* Makefile.am:  Update to match latest tree.
 	* Makefile.in: Regenerate.
 	* testsuite/lib/libvtv: Brought up to date.
@@ -24,15 +24,13 @@ 2015-02-09  Thomas Schwinge  
+2015-01-29  Patrick Wollgast  
 
-	Committing VTV Cywin/Ming patch for Patrick Wollgast
 	* libvtv/Makefile.in : Regenerate.
 	* libvtv/configure : Regenerate.
 
-2015-01-28  Caroline Tice  
+2015-01-28  Patrick Wollgast  
 
-	Committing VTV Cywin/Ming patch for Patrick Wollgast
 	* libvtv/Makefile.am : Add libvtv.la to toolexeclib_LTLIBRARIES, if
 	VTV_CYGMIN is set. Define libvtv_la_LIBADD, libvtv_la_LDFLAGS,
 	libvtv_stubs_la_LDFLAGS and libvtv_stubs_la_SOURCES if VTV_CYGMIN is
diff --git a/libvtv/vtv_fail.cc b/libvtv/vtv_fail.cc
--- a/libvtv/vtv_fail.cc
+++ b/libvtv/vtv_fail.cc
@@ -38,9 +38,7 @@
desired.  This may be the case if the programmer has to deal wtih
unverified third party software, for example.  __vtv_really_fail is
available for the programmer to call from his version of
-   __vtv_verify_fail, if he decides the failure is real.
-
-*/
+   __vtv_verify_fail, if he decides the failure is real.  */
 
 #include 
 #include 
@@ -80,8 +78,8 @@ const unsigned long SET_HANDLE_HANDLE_BI
 
 /* Instantiate the template classes (in vtv_set.h) for our particular
hash table needs.  */
-typedef void * vtv_set_handle;
-typedef vtv_set_handle * vtv_set_handle_handle; 
+typedef void *vtv_set_handle;
+typedef vtv_set_handle *vtv_set_handle_handle; 
 
 static int vtv_failures_log_fd = -1;
 
@@ -121,17 +119,16 @@ log_error_message (const char *log_msg, 
variable.  */
 
 static inline bool
-is_set_handle_handle (void * ptr)
+is_set_handle_handle (void *ptr)
 {
-  return ((unsigned long) ptr & SET_HANDLE_HANDLE_BIT)
-  == SET_HANDLE_HANDLE_BIT;
+  return ((unsigned long) ptr & SET_HANDLE_HANDLE_BIT) == SET_HANDLE_HANDLE_BIT;
 }
 
 /* Returns the actual pointer value of a vtable map variable, PTR (see
comments for is_set_handle_handle for more details).  */
 
 static inline vtv_set_handle * 
-ptr_from_set_handle_handle (void * ptr)
+ptr_from_set_handle_handle (void *ptr)
 {
   return (vtv_set_handle *) ((unsigned long) ptr & ~SET_HANDLE_HANDLE_BIT);
 }
@@ -141,7 +138,7 @@ ptr_from_set_handle_handle (void * ptr)
variable.  */
 
 static inline vtv_set_handle_handle
-set_handle_handle (vtv_set_handle * ptr)
+set_handle_handle (vtv_set_handle *ptr)
 {
   return (vtv_set_handle_handle) ((unsigned long) ptr | SET_HANDLE_HANDLE_BIT);
 }
@@ -151,7 +148,7 @@ set_handle_handle (vtv_set_handle * ptr)
file, then calls __vtv_verify_fail.  SET_HANDLE_PTR is the pointer
to the set of valid vtable pointers, VTBL_PTR is the pointer that
was not found in the set, and DEBUG_MSG is the message to be
-   written to the log file before failing. n */
+   written to the log file before failing.  */
 
 void
 __vtv_verify_fail_debug (void **set_handle_ptr, const void *vtbl_ptr, 
@@ -197,9 +194,9 @@ vtv_fail (const char *msg, void **data_s
  "*** Unable to verify vtable pointer (%p) in set (%p) *** \n";
 
   snprintf (buffer, sizeof (buffer), format_str, vtbl_ptr,
-is_set_handle_handle(*data_set_ptr) ?
-  ptr_from_set_handle_handle (*data_set_ptr) :
-	  *data_set_ptr);
+is_set_handle_handle(*data_set_ptr)
+	? ptr_from_set_handle_handle (*data_set_ptr)
+	: *data_set_ptr);
   buf_len = strlen (buffer);
   /*  Send this to to stderr.  */
   write (2, buffer, buf_len);
@@ -221,9 +218,9 @@ void
   char log_msg[256];
   snprintf (log_msg,