git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Elijah Newren <newren@gmail.com>,
	"Randall S. Becker" <rsbecker@nexbridge.com>,
	git@vger.kernel.org
Subject: Re: [ANNOUNCE] git-2.30.0-rc0 - Compile Fails on HPE NonStop
Date: Mon, 14 Dec 2020 21:52:52 -0500	[thread overview]
Message-ID: <X9glBJnlLMTW6Dns@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqqeejraiw7.fsf@gitster.c.googlers.com>

On Mon, Dec 14, 2020 at 06:43:36PM -0800, Junio C Hamano wrote:

> diff --git c/git-compat-util.h w/git-compat-util.h
> index 7d509c5022..58cd0761be 100644
> --- c/git-compat-util.h
> +++ w/git-compat-util.h
> @@ -273,7 +273,8 @@ struct itimerval {
>  
>  #ifdef NO_SETITIMER
>  static inline int setitimer(int which, const struct itimerval *value, struct itimerval *newvalue) {
> -	; /* nothing */
> +	errno = ENOSYS;
> +	return -1; /* not implemented */
>  }
>  #endif
>  
> Alternatively we could pretend that the call always succeeds by
> without touching errno and returning 0.  That might be safer, but I
> dunno which one we want, and I do not have a system affected by the
> choice.

I think this is a sensible choice. Before the conversion to an inline,
the code was removed entirely! So anybody checking the return value
would have seen an error, and we do not have to worry much about
breaking them.

For new callers, anybody checking the return value would probably
appreciate the warning that support for the function is optional (OTOH,
they would probably not find out themselves, but rather when Randall
tells them ;) ).

It would be nice to have a way to warn them even on platforms that have
setitimer(), but I can't think of an easy way.

> > Aside from inlining bodies, this should not have compiled on any platform:
> >
> > static inline void strset_remove(struct strset *set, const char *str)
> > {
> >         return strmap_remove(&set->map, str, 0);
> > }
> >
> > What is really intended here?
> 
> I think we should just drop "return"; a void function should be
> called in void context without requiring a value, even if that
> return expects no value.

Yeah, I think that is right. I checked earlier iterations of the series
to see if perhaps strmap_remove() had previously returned a value, but
it never did in any on the list.

> diff --git i/strmap.h w/strmap.h
> index c4c104411b..1e152d832d 100644
> --- i/strmap.h
> +++ w/strmap.h
> @@ -165,7 +165,7 @@ static inline int strintmap_contains(struct strintmap *map, const char *str)
>  
>  static inline void strintmap_remove(struct strintmap *map, const char *str)
>  {
> -	return strmap_remove(&map->map, str, 0);
> +	strmap_remove(&map->map, str, 0);
>  }

So yeah, I think that is the right fix. +cc Elijah for any other
insight.

-Peff

  reply	other threads:[~2020-12-15  2:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-14 23:12 [ANNOUNCE] git-2.30.0-rc0 - Compile Fails on HPE NonStop Randall S. Becker
2020-12-15  2:43 ` Junio C Hamano
2020-12-15  2:52   ` Jeff King [this message]
2020-12-15 15:55     ` Randall S. Becker
2020-12-15 16:21     ` Elijah Newren
2020-12-15 21:07       ` Junio C Hamano
2020-12-15 21:08       ` Junio C Hamano
2020-12-15 21:25         ` [PATCH] strmap: make callers of strmap_remove() to call it in void context Junio C Hamano
2020-12-15 21:35           ` Randall S. Becker
2020-12-15 21:26         ` [PATCH] compat-util: pretend that stub setitimer() always succeeds Junio C Hamano
2020-12-15 21:37         ` [ANNOUNCE] git-2.30.0-rc0 - Compile Fails on HPE NonStop Jeff King
2020-12-16 17:27           ` Junio C Hamano

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=X9glBJnlLMTW6Dns@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=newren@gmail.com \
    --cc=rsbecker@nexbridge.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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).