Fixed
Status Update
Comments
su...@google.com <su...@google.com> #2
the error happens when calling UrlFetchApp.fetch()
en...@google.com <en...@google.com>
da...@google.com <da...@google.com>
da...@google.com <da...@google.com> #3
This happens in a published add-in
br...@gmail.com <br...@gmail.com> #4
I'm calling the same URL API endpoints from Google script editor UrlFetchApp.fetch("URL") and Google sheets (IMPORTDATA("URL"). This is what I've experienced since evening 8th Dec CET:
GAS: It happens consistently when calling UrlFetchApp.fetch("URL"). The same http URL query works fine outside of the Google environment.
Google sheet: At the same time started to experience unsuccessful calls when using IMPORTDATA("URL") in Google sheets. The calls seems to work on/off if I change the query a bit, for a call or two. Outside of the Google environment the calls are successful.
I have looked in vain if there are any restrictions in our Google account. Anyone have a clue on how to resolve this?
GAS: It happens consistently when calling UrlFetchApp.fetch("URL"). The same http URL query works fine outside of the Google environment.
Google sheet: At the same time started to experience unsuccessful calls when using IMPORTDATA("URL") in Google sheets. The calls seems to work on/off if I change the query a bit, for a call or two. Outside of the Google environment the calls are successful.
I have looked in vain if there are any restrictions in our Google account. Anyone have a clue on how to resolve this?
en...@google.com <en...@google.com> #5
same for me, got same problems
da...@google.com <da...@google.com> #6
same here, got same issue - it affect all our users and not just random.
da...@google.com <da...@google.com> #7
We're also experiencing this issue when calling UrlFetchApp.fetch()
Our production system is down.
Description
"If the function determines that the next multibyte character is complete and valid, it determines the values of the corresponding wide characters and then, if pc16 is not a null pointer, stores the value of the first (or only) such character in the object pointed to by pc16. Subsequent calls will store successive wide characters without consuming any additional input until all the characters have been stored."
A small positive return value indicates that "the next n or fewer bytes complete a valid multibyte character (which is the value stored); the value returned is the number of bytes that complete the multibyte character."
The return value (size_t)(-3) indicates that "the next character resulting from a previous call has been stored (no bytes from the input have been consumed by this call)".
So, when the input is a Unicode character outside the BMP, the first mbrtoc16() call should return the number of bytes (= 4), whereas the second mbrtoc16() call should return (size_t)(-3).
Test case:
========================= foo.c =========================
#include <locale.h>
#include <stdio.h>
#include <string.h>
#include <wchar.h>
#include <uchar.h>
int main ()
{
if (setlocale (LC_ALL, "en_US.UTF-8") == NULL)
return 1;
char input[] = "\360\237\230\213"; /* U+1F60B */
mbstate_t state;
char16_t wc;
size_t ret;
memset (&state, '\0', sizeof (mbstate_t));
wc = (char16_t) 0xBADF;
ret = mbrtoc16 (&wc, input, 4, &state);
printf ("First mbrtoc16 call: wc = 0x%04X, ret = %d\n", wc, (int) ret);
ret = mbrtoc16 (&wc, input + 4, 0, &state);
printf ("Second mbrtoc16 call: wc = 0x%04X, ret = %d\n", wc, (int) ret);
return 0;
}
========================================================
Compile and run this program (e.g. under termux).
Expected output (seen e.g. in musl libc, which is generally very standards compliant, and GNU libc):
First mbrtoc16 call: wc = 0xD83D, ret = 4
Second mbrtoc16 call: wc = 0xDE0B, ret = -3
Actual output (on Android 11):
First mbrtoc16 call: wc = 0xD83D, ret = -3
Second mbrtoc16 call: wc = 0xDE0B, ret = 4
Returning (size_t)(-3) in the first call is wrong, because that is not "the next character from a previous call".