threads / patch / 38510

v3, 7 partsRe: [Qemu-devel] [PATCH v3 0/7] cpu: add device_add foo-x86_64-cpu support

Subject: Re: [Qemu-devel] [PATCH v3 0/7] cpu: add device_add foo-x86_64-cpu support

## tl;dr

7 messages between Feb 5, 2015 and Feb 18, 2015. Diffs are folded; open one to read it.

replies: 6people: 3as markdown or json

Eric Blake· Feb 5, 2015, 15:25 UTC · lore
[adding git list to cc]
On 02/05/2015 04:49 AM, Stefan Hajnoczi wrote:
Show 10 quoted lines
> On Wed, Jan 14, 2015 at 03:27:23PM +0800, Zhu Guihua wrote:
>> This series is based on the previous patchset from Chen Fan:
>> https://lists.nongnu.org/archive/html/qemu-devel/2014-05/msg02360.html
> 
> This email has an invalid charset:
> Content-Type: text/plain; charset="y"
> 
> I guess you entered "y" when asked how the message was encoded.
> 
> Please don't do that, it means we can only guess at the charset.

In the past, people made a similar problem when 'git send-email' was asking if a message was in-reply-to something else (the number of messages incorrectly threaded to a message-id of 'y' or 'n' was evidence of the poor quality of the question). git.git commit 51bbccfd1b4a corrected that problem. Sounds like charset encoding is another case where the interactive parser should be taught to balk at nonsense encoding answers?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Junio C Hamano· Feb 5, 2015, 19:29 UTC · re: Eric Blake · lore
Eric Blake <eblake@redhat.com> writes:
Show 19 quoted lines
> On 02/05/2015 04:49 AM, Stefan Hajnoczi wrote:
>> On Wed, Jan 14, 2015 at 03:27:23PM +0800, Zhu Guihua wrote:
>>> This series is based on the previous patchset from Chen Fan:
>>> https://lists.nongnu.org/archive/html/qemu-devel/2014-05/msg02360.html
>> 
>> This email has an invalid charset:
>> Content-Type: text/plain; charset="y"
>> 
>> I guess you entered "y" when asked how the message was encoded.
>> 
>> Please don't do that, it means we can only guess at the charset.
>
> In the past, people made a similar problem when 'git send-email' was
> asking if a message was in-reply-to something else (the number of
> messages incorrectly threaded to a message-id of 'y' or 'n' was evidence
> of the poor quality of the question).  git.git commit 51bbccfd1b4a
> corrected that problem.  Sounds like charset encoding is another case
> where the interactive parser should be taught to balk at nonsense
> encoding answers?

I think I answered this in $gmane/263354; care to come up with a plausible valid_re? It is inpractical to attempt to cover all valid charset names, so whatever you do I'd imagine you would want to pass the confirm_only parameter set to true.

Jeff King· Feb 5, 2015, 19:57 UTC · re: Junio C Hamano · lore
On Thu, Feb 05, 2015 at 11:29:07AM -0800, Junio C Hamano wrote:
Show 26 quoted lines
> Eric Blake <eblake@redhat.com> writes:
> 
> > On 02/05/2015 04:49 AM, Stefan Hajnoczi wrote:
> >> On Wed, Jan 14, 2015 at 03:27:23PM +0800, Zhu Guihua wrote:
> >>> This series is based on the previous patchset from Chen Fan:
> >>> https://lists.nongnu.org/archive/html/qemu-devel/2014-05/msg02360.html
> >> 
> >> This email has an invalid charset:
> >> Content-Type: text/plain; charset="y"
> >> 
> >> I guess you entered "y" when asked how the message was encoded.
> >> 
> >> Please don't do that, it means we can only guess at the charset.
> >
> > In the past, people made a similar problem when 'git send-email' was
> > asking if a message was in-reply-to something else (the number of
> > messages incorrectly threaded to a message-id of 'y' or 'n' was evidence
> > of the poor quality of the question).  git.git commit 51bbccfd1b4a
> > corrected that problem.  Sounds like charset encoding is another case
> > where the interactive parser should be taught to balk at nonsense
> > encoding answers?
> 
> I think I answered this in $gmane/263354; care to come up with a
> plausible valid_re?  It is inpractical to attempt to cover all valid
> charset names, so whatever you do I'd imagine you would want to pass
> the confirm_only parameter set to true.

Would "length() > 1" be enough[1]? Or are people really typing "yes" and not just "y"?

I cannot imagine a charset name that is smaller than two characters. It may be that there are none smaller than 4, and we could cut it off there. Googling around for some lists of common charsets, it seems like that might be plausible (but not any larger; "big5" is 4 characters, and people may spell "utf8" without the hyphen).

-Peff
[1] Of course, to match the existing regex code, we may want to spell
    this as "/../" or "/..../".
Junio C Hamano· Feb 5, 2015, 20:17 UTC · re: Jeff King · lore
Jeff King <peff@peff.net> writes:
Show 42 quoted lines
> On Thu, Feb 05, 2015 at 11:29:07AM -0800, Junio C Hamano wrote:
>
>> Eric Blake <eblake@redhat.com> writes:
>> 
>> > On 02/05/2015 04:49 AM, Stefan Hajnoczi wrote:
>> >> On Wed, Jan 14, 2015 at 03:27:23PM +0800, Zhu Guihua wrote:
>> >>> This series is based on the previous patchset from Chen Fan:
>> >>> https://lists.nongnu.org/archive/html/qemu-devel/2014-05/msg02360.html
>> >> 
>> >> This email has an invalid charset:
>> >> Content-Type: text/plain; charset="y"
>> >> 
>> >> I guess you entered "y" when asked how the message was encoded.
>> >> 
>> >> Please don't do that, it means we can only guess at the charset.
>> >
>> > In the past, people made a similar problem when 'git send-email' was
>> > asking if a message was in-reply-to something else (the number of
>> > messages incorrectly threaded to a message-id of 'y' or 'n' was evidence
>> > of the poor quality of the question).  git.git commit 51bbccfd1b4a
>> > corrected that problem.  Sounds like charset encoding is another case
>> > where the interactive parser should be taught to balk at nonsense
>> > encoding answers?
>> 
>> I think I answered this in $gmane/263354; care to come up with a
>> plausible valid_re?  It is inpractical to attempt to cover all valid
>> charset names, so whatever you do I'd imagine you would want to pass
>> the confirm_only parameter set to true.
>
> Would "length() > 1" be enough[1]? Or are people really typing "yes" and
> not just "y"?
>
> I cannot imagine a charset name that is smaller than two characters. It
> may be that there are none smaller than 4, and we could cut it off
> there. Googling around for some lists of common charsets, it seems like
> that might be plausible (but not any larger; "big5" is 4 characters, and
> people may spell "utf8" without the hyphen).
>
> -Peff
>
> [1] Of course, to match the existing regex code, we may want to spell
>     this as "/../" or "/..../".

Perhaps. Just in case there were shorter ones, something like this with confirm_only to allow them to say "Yes, I do mean 'xx'"?

 git-send-email.perl | 1 +
 1 file changed, 1 insertion(+)
Show changes to git-send-email.perl +1 −0
diff --git a/git-send-email.perl b/git-send-email.perl
index 3092ab3..848f176 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -752,6 +752,7 @@ sub file_declares_8bit_cte {
 		print "    $f\n";
 	}
 	$auto_8bit_encoding = ask("Which 8bit encoding should I declare [UTF-8]? ",
+				  valid_re => qr/.{4}/, confirm_only => 1,
 				  default => "UTF-8");
 }
 
Jeff King· Feb 6, 2015, 19:33 UTC · re: Junio C Hamano · lore
On Thu, Feb 05, 2015 at 12:17:15PM -0800, Junio C Hamano wrote:
Show 31 quoted lines
> > Would "length() > 1" be enough[1]? Or are people really typing "yes" and
> > not just "y"?
> >
> > I cannot imagine a charset name that is smaller than two characters. It
> > may be that there are none smaller than 4, and we could cut it off
> > there. Googling around for some lists of common charsets, it seems like
> > that might be plausible (but not any larger; "big5" is 4 characters, and
> > people may spell "utf8" without the hyphen).
> >
> > -Peff
> >
> > [1] Of course, to match the existing regex code, we may want to spell
> >     this as "/../" or "/..../".
> 
> Perhaps. Just in case there were shorter ones, something like this
> with confirm_only to allow them to say "Yes, I do mean 'xx'"?
> 
>  git-send-email.perl | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 3092ab3..848f176 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -752,6 +752,7 @@ sub file_declares_8bit_cte {
>  		print "    $f\n";
>  	}
>  	$auto_8bit_encoding = ask("Which 8bit encoding should I declare [UTF-8]? ",
> +				  valid_re => qr/.{4}/, confirm_only => 1,
>  				  default => "UTF-8");
>  }
Yes, I think leaving an escape hatch is a good idea, just in case.
-Peff
Junio C Hamano· Feb 16, 2015, 22:34 UTC · re: Jeff King · lore

[PATCH] send-email: ask confirmation if given encoding name is very short

Sometimes people respond "y<ENTER>" (or "yes<ENTER>") when asked this question:

    Which 8bit encoding should I declare [UTF-8]?

We already have a mechanism to avoid accepting a mistyped e-mail address (we ask to confirm when the given address lacks "@" in it); reuse it to trigger the same confirmation when given a very short answer. As a typical charset name is probably at least 4 chars or longer (e.g. "UTF8" spelled without the dash, or "Big5"), this would prevent such a mistake.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 * Will mark to be merged to 'next'.
 git-send-email.perl | 1 +
 1 file changed, 1 insertion(+)
Show changes to git-send-email.perl +1 −0
diff --git a/git-send-email.perl b/git-send-email.perl
index fdb0029..eb32371 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -733,6 +733,7 @@ sub file_declares_8bit_cte {
 		print "    $f\n";
 	}
 	$auto_8bit_encoding = ask("Which 8bit encoding should I declare [UTF-8]? ",
+				  valid_re => qr/.{4}/, confirm_only => 1,
 				  default => "UTF-8");
 }
 
-- 
2.3.0-282-gf18c841
Jeff King· Feb 18, 2015, 18:58 UTC · re: Junio C Hamano · lore

Re: [PATCH] send-email: ask confirmation if given encoding name is very short

On Mon, Feb 16, 2015 at 02:34:14PM -0800, Junio C Hamano wrote:
Show 16 quoted lines
> Sometimes people respond "y<ENTER>" (or "yes<ENTER>") when asked
> this question:
> 
>     Which 8bit encoding should I declare [UTF-8]?
> 
> We already have a mechanism to avoid accepting a mistyped e-mail
> address (we ask to confirm when the given address lacks "@" in it);
> reuse it to trigger the same confirmation when given a very short
> answer.  As a typical charset name is probably at least 4 chars or
> longer (e.g. "UTF8" spelled without the dash, or "Big5"), this would
> prevent such a mistake.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> 
>  * Will mark to be merged to 'next'.
Probably belated review, but this looks good to me.
-Peff

← back to recent threads