public inbox for glibc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Adhemerval Zanella <azanella@sourceware.org>
To: glibc-cvs@sourceware.org
Subject: [glibc] nscd: Remove _STRING_ARCH_unaligned usage
Date: Fri, 17 Feb 2023 19:05:34 +0000 (GMT)	[thread overview]
Message-ID: <20230217190534.2011D385B51A@sourceware.org> (raw)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=f281a955e9fa154296e7ff7620005114808c58d9

commit f281a955e9fa154296e7ff7620005114808c58d9
Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Date:   Fri Feb 10 10:54:47 2023 -0300

    nscd: Remove _STRING_ARCH_unaligned usage
    
    It only adds a small overhead for unaligned inputs (which should not
    be common) and unify the code.
    
    Checked on x86_64-linux-gnu and i686-linux-gnu.
    
    Reviewed-by: Wilco Dijkstra  <Wilco.Dijkstra@arm.com>

Diff:
---
 nscd/nscd_gethst_r.c  | 2 --
 nscd/nscd_getserv_r.c | 2 --
 nscd/nscd_helper.c    | 6 ------
 3 files changed, 10 deletions(-)

diff --git a/nscd/nscd_gethst_r.c b/nscd/nscd_gethst_r.c
index 7950ed695c..153194ad04 100644
--- a/nscd/nscd_gethst_r.c
+++ b/nscd/nscd_gethst_r.c
@@ -185,7 +185,6 @@ nscd_gethst_r (const char *key, size_t keylen, request_type type,
 	      goto out;
 	    }
 
-#if !_STRING_ARCH_unaligned
 	  /* The aliases_len array in the mapped database might very
 	     well be unaligned.  We will access it word-wise so on
 	     platforms which do not tolerate unaligned accesses we
@@ -199,7 +198,6 @@ nscd_gethst_r (const char *key, size_t keylen, request_type type,
 				    hst_resp.h_aliases_cnt
 				    * sizeof (uint32_t));
 	    }
-#endif
 	  if (type != GETHOSTBYADDR && type != GETHOSTBYNAME)
 	    {
 	      if (hst_resp.h_length == INADDRSZ)
diff --git a/nscd/nscd_getserv_r.c b/nscd/nscd_getserv_r.c
index 752ae1115e..0ee83ff88c 100644
--- a/nscd/nscd_getserv_r.c
+++ b/nscd/nscd_getserv_r.c
@@ -140,7 +140,6 @@ nscd_getserv_r (const char *crit, size_t critlen, const char *proto,
 				> recend, 0))
 	    goto out;
 
-#if !_STRING_ARCH_unaligned
 	  /* The aliases_len array in the mapped database might very
 	     well be unaligned.  We will access it word-wise so on
 	     platforms which do not tolerate unaligned accesses we
@@ -170,7 +169,6 @@ nscd_getserv_r (const char *crit, size_t critlen, const char *proto,
 				    serv_resp.s_aliases_cnt
 				    * sizeof (uint32_t));
 	    }
-#endif
 	}
     }
 
diff --git a/nscd/nscd_helper.c b/nscd/nscd_helper.c
index fdd555ea66..6a498b363c 100644
--- a/nscd/nscd_helper.c
+++ b/nscd/nscd_helper.c
@@ -465,7 +465,6 @@ __nscd_cache_search (request_type type, const char *key, size_t keylen,
       struct hashentry *here = (struct hashentry *) (mapped->data + work);
       ref_t here_key, here_packet;
 
-#if !_STRING_ARCH_unaligned
       /* Although during garbage collection when moving struct hashentry
 	 records around we first copy from old to new location and then
 	 adjust pointer from previous hashentry to it, there is no barrier
@@ -474,7 +473,6 @@ __nscd_cache_search (request_type type, const char *key, size_t keylen,
 	 application.  */
       if ((uintptr_t) here & (__alignof__ (*here) - 1))
 	return NULL;
-#endif
 
       if (type == here->type
 	  && keylen == here->len
@@ -487,10 +485,8 @@ __nscd_cache_search (request_type type, const char *key, size_t keylen,
 	  struct datahead *dh
 	    = (struct datahead *) (mapped->data + here_packet);
 
-#if !_STRING_ARCH_unaligned
 	  if ((uintptr_t) dh & (__alignof__ (*dh) - 1))
 	    return NULL;
-#endif
 
 	  /* See whether we must ignore the entry or whether something
 	     is wrong because garbage collection is in progress.  */
@@ -511,11 +507,9 @@ __nscd_cache_search (request_type type, const char *key, size_t keylen,
 	  struct hashentry *trailelem;
 	  trailelem = (struct hashentry *) (mapped->data + trail);
 
-#if !_STRING_ARCH_unaligned
 	  /* We have to redo the checks.  Maybe the data changed.  */
 	  if ((uintptr_t) trailelem & (__alignof__ (*trailelem) - 1))
 	    return NULL;
-#endif
 
 	  if (trail + MINIMUM_HASHENTRY_SIZE > datasize)
 	    return NULL;

                 reply	other threads:[~2023-02-17 19:05 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230217190534.2011D385B51A@sourceware.org \
    --to=azanella@sourceware.org \
    --cc=glibc-cvs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).