Why does sscanf fail to scan "" ? Bug?
The below test code demonstrates that sscanf fails
to parse the string "" (ie. an empty string inside "") in line2 (fErr=1).
Is this a bug?
Or is there maybe a workaround format string to be used with sscanf ?
/*
sscanf_bug_demo.cpp
sscanf fails scanning the string ""
Compile:
g++ -g -Wall -Wextra -std=c++11 sscanf_bug_demo.cpp
Run:
./a.out
Input lines:
joe "prj 1" "blah foo"
jim "" "quantum leap"
Output:
line1: n=3 : fErr=0 : un="joe" prj="prj 1" desc="blah foo"
line2: n=1 : fErr=1 : un="jim" prj="" desc=""
*/
#include
// using namespace std;
void sscanf_bug_demo()
{ // sscanf fails scanning the string ""
// test data:
// line format: username "prj" "desc"(the string in "" can be empty)
const char* line1 = "joe \"prj 1\" \"blah foo\"";
const char* line2 = "jim \"\" \"quantum leap\"";
char un[32], prj[16], desc[256];
int n;
bool fErr;
// parsing via sscanf:
un[0] = 0, prj[0] = 0, desc[0] = 0; // clear them before filling
n = sscanf(line1, "%31[^ ] \"%15[^\"]\" \"%255[^\"]\"", un, prj, desc);
fErr = n < 3;
printf("line1: n=%d : fErr=%d : un=\"%s\" prj=\"%s\" desc=\"%s\"\n",
n, fErr, un, prj, desc);
un[0] = 0, prj[0] = 0, desc[0] = 0; // clear them before filling
n = sscanf(line2, "%31[^ ] \"%15[^\"]\" \"%255[^\"]\"", un, prj, desc);
fErr = n < 3;
printf("line2: n=%d : fErr=%d : un=\"%s\" prj=\"%s\" desc=\"%s\"\n",
n, fErr, un, prj, desc);
}
int main()
{
sscanf_bug_demo();
return 0;
}
Re: Why does sscanf fail to scan "" ? Bug?
The man page for sscanf on my machine indicates that [ "matches a
nonempty sequence of characters", so failing to match an empty
character sequence seems to be correct behavior.
On Mon, Jul 15, 2024 at 10:16 PM U.Mutlu wrote:
>
> The below test code demonstrates that sscanf fails
> to parse the string "" (ie. an empty string inside "") in line2 (fErr=1).
> Is this a bug?
> Or is there maybe a workaround format string to be used with sscanf ?
>
> /*
> sscanf_bug_demo.cpp
>
> sscanf fails scanning the string ""
>
> Compile:
>g++ -g -Wall -Wextra -std=c++11 sscanf_bug_demo.cpp
>
> Run:
>./a.out
>
> Input lines:
>joe "prj 1" "blah foo"
>jim "" "quantum leap"
>
> Output:
>line1: n=3 : fErr=0 : un="joe" prj="prj 1" desc="blah foo"
>line2: n=1 : fErr=1 : un="jim" prj="" desc=""
> */
>
> #include
> // using namespace std;
>
> void sscanf_bug_demo()
>{ // sscanf fails scanning the string ""
>
> // test data:
> // line format: username "prj" "desc"(the string in "" can be empty)
> const char* line1 = "joe \"prj 1\" \"blah foo\"";
> const char* line2 = "jim \"\" \"quantum leap\"";
>
> char un[32], prj[16], desc[256];
> int n;
> bool fErr;
>
> // parsing via sscanf:
>
> un[0] = 0, prj[0] = 0, desc[0] = 0; // clear them before filling
> n = sscanf(line1, "%31[^ ] \"%15[^\"]\" \"%255[^\"]\"", un, prj, desc);
> fErr = n < 3;
> printf("line1: n=%d : fErr=%d : un=\"%s\" prj=\"%s\" desc=\"%s\"\n",
>n, fErr, un, prj, desc);
>
> un[0] = 0, prj[0] = 0, desc[0] = 0; // clear them before filling
> n = sscanf(line2, "%31[^ ] \"%15[^\"]\" \"%255[^\"]\"", un, prj, desc);
> fErr = n < 3;
> printf("line2: n=%d : fErr=%d : un=\"%s\" prj=\"%s\" desc=\"%s\"\n",
>n, fErr, un, prj, desc);
>}
>
> int main()
>{
> sscanf_bug_demo();
> return 0;
>}
>
Re: Why does sscanf fail to scan "" ? Bug?
On Mon, 15 Jul 2024 at 14:16, U.Mutlu wrote: > > The below test code demonstrates that sscanf fails > to parse the string "" (ie. an empty string inside "") in line2 (fErr=1). > Is this a bug? This mailing list is for discussing the development of GCC, and sscanf is not part of GCC. The behaviour you're seeing is not caused by GCC (and is not a bug). > Or is there maybe a workaround format string to be used with sscanf ? If sscanf returns 1 it means it failed to scan the "%15[^"]" string, so you could try again using "" in the pattern.
Re: Insn combine trying (ior:HI (clobber:HI (const_int 0)))
Georg-Johann Lay writes:
> In a test case I see insn combine trying to match such
> expressions, which do not make any sense to me, like:
>
> Trying 2 -> 7:
> 2: r45:HI=r48:HI
>REG_DEAD r48:HI
> 7: {r47:HI=r45:HI|r46:PSI#0;clobber scratch;}
>REG_DEAD r46:PSI
>REG_DEAD r45:HI
> Failed to match this instruction:
> (parallel [
> (set (reg:HI 47 [ _4 ])
> (ior:HI (clobber:HI (const_int 0 [0]))
> (reg:HI 48)))
> (clobber (scratch:QI))
> ])
>
> and many other occasions like that.
>
> Is this just insn combine doing its business?
>
> Or should this be some sensible RTL instead?
>
> Seen on target avr with v14 and trunk,
> attached test case and dump compiled with
(clobber:M (const_int 0)) is combine's way of representing
"something went wrong here". And yeah, recog acts as an error
detection mechanism in these cases. In other words, the idea
is that recog should eventually fail on nonsense rtl like that,
so earlier code doesn't need to check explicitly.
Richard
>
> $ avr-gcc-14 strange.c -S -Os -dp -da
>
> Johann
Re: GCC 11.5 Release Candidate available from gcc.gnu.org
On 7/12/24 7:47 AM, Richard Biener via Gcc wrote: The first release candidate for GCC 11.5 is available from https://gcc.gnu.org/pub/gcc/snapshots/11.5.0-RC-20240712/ and shortly its mirrors. It has been generated from git commit r11-11573-g30ffca55041518. I have so far bootstrapped and tested the release candidate on x86_64-linux. Please test it and report any issues to bugzilla. If all goes well, we'd like to release 11.5 on Friday, July 19th. The GCC 11 branch will be closed after this release. I tried all the usual powerpc64 variations both BE and LE and the only possible issue I noticed was the ICE from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109573 is still present.
Re: GCC 11.5 Release Candidate available from gcc.gnu.org
> Am 15.07.2024 um 20:07 schrieb William Seurer via Gcc : > > On 7/12/24 7:47 AM, Richard Biener via Gcc wrote: >> The first release candidate for GCC 11.5 is available from >> >> https://gcc.gnu.org/pub/gcc/snapshots/11.5.0-RC-20240712/ >> >> and shortly its mirrors. It has been generated from git commit >> r11-11573-g30ffca55041518. >> >> I have so far bootstrapped and tested the release candidate on >> x86_64-linux. >> Please test it and report any issues to bugzilla. >> >> If all goes well, we'd like to release 11.5 on Friday, July 19th. >> >> The GCC 11 branch will be closed after this release. > > > I tried all the usual powerpc64 variations both BE and LE and the only > possible issue I noticed was the ICE from > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109573 is still present As noted in the audit trail that’s expected with checking enabled. Richard
