Saturday, 27 May 2023

Re: "error: ‘t.data.character.ptr’ may be used uninitialized " when building hubbub with gcc 11

From 69d81a8a4d4c223aad67cde0fdf64d64351b9802 Mon Sep 17 00:00:00 2001
From: Andy Tai <atai@atai.org>
Date: Sat, 27 May 2023 00:01:34 -0700
Subject: [PATCH] prevent -Werror=maybe-uninitialized build failure with gcc 11
when building tests tokeniser2 and tokeniser3

---
test/tokeniser2.c | 2 +-
test/tokeniser3.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/test/tokeniser2.c b/test/tokeniser2.c
index c8ab9c0..4caae38 100644
--- a/test/tokeniser2.c
+++ b/test/tokeniser2.c
@@ -438,7 +438,7 @@ hubbub_error token_handler(const hubbub_token *token, void *pw)
/* Expected token only contained part of the data
* Calculate how much is left, then try again with
* the next expected token */
- hubbub_token t;
+ hubbub_token t = { 0 };

t.type = HUBBUB_TOKEN_CHARACTER;
t.data.character.ptr += len;
diff --git a/test/tokeniser3.c b/test/tokeniser3.c
index e33d018..b3be901 100644
--- a/test/tokeniser3.c
+++ b/test/tokeniser3.c
@@ -447,7 +447,7 @@ hubbub_error token_handler(const hubbub_token *token, void *pw)
/* Expected token only contained part of the data
* Calculate how much is left, then try again with
* the next expected token */
- hubbub_token t;
+ hubbub_token t = { 0 };

t.type = HUBBUB_TOKEN_CHARACTER;
t.data.character.ptr += len;
--
2.40.1

patch to get rid of the warning:


On Thu, May 25, 2023 at 12:16 PM Andy Tai <atai@atai.org> wrote:
>
> Hi, I found from GNU Guix's build check that when building with gcc 11,
>
> building hubbub would fail when building tests with errors like
>
> COMPILE: test/tokeniser2.c
> COMPILE: test/tokeniser3.c
> COMPILE: test/tree.c
> COMPILE: test/tree2.c
> COMPILE: test/tree-buf.c
> test/tokeniser2.c: In function 'token_handler':
> test/tokeniser2.c:444:46: error: 't.data.character.ptr' may be used
> uninitialized [-Werror=maybe-uninitialized]
> 444 | t.data.character.ptr += len;
> | ^~
> test/tokeniser2.c:441:38: note: 't' declared here
> 441 | hubbub_token t;
> | ^
> test/tokeniser2.c:445:46: error: 't.data.character.len' may be used
> uninitialized [-Werror=maybe-uninitialized]
> 445 | t.data.character.len -= len;
> | ^~
>
> ...
>
> I briefly took a look of the test source code in question and the
> hubbub_token structs seem not explicitly initialized. Is this a real
> warning from gcc of possibly uninitialized variable which can cause
> the build to fail if allow warnings are treated as errors by gcc
> during build (a common practice)? Thanks if maintainer can take a
> look.
>
> relevant bug entry and complete bug logs:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63526



--
Andy Tai, atai@atai.org, Skype: licheng.tai, Line: andy_tai, WeChat: andytai1010
Year 2023 民國112年
自動的精神力是信仰與覺悟
自動的行為力是勞動與技能

Thursday, 25 May 2023

"error: ‘t.data.character.ptr’ may be used uninitialized " when building hubbub with gcc 11

Hi, I found from GNU Guix's build check that when building with gcc 11,

building hubbub would fail when building tests with errors like

COMPILE: test/tokeniser2.c
COMPILE: test/tokeniser3.c
COMPILE: test/tree.c
COMPILE: test/tree2.c
COMPILE: test/tree-buf.c
test/tokeniser2.c: In function 'token_handler':
test/tokeniser2.c:444:46: error: 't.data.character.ptr' may be used
uninitialized [-Werror=maybe-uninitialized]
444 | t.data.character.ptr += len;
| ^~
test/tokeniser2.c:441:38: note: 't' declared here
441 | hubbub_token t;
| ^
test/tokeniser2.c:445:46: error: 't.data.character.len' may be used
uninitialized [-Werror=maybe-uninitialized]
445 | t.data.character.len -= len;
| ^~

...

I briefly took a look of the test source code in question and the
hubbub_token structs seem not explicitly initialized. Is this a real
warning from gcc of possibly uninitialized variable which can cause
the build to fail if allow warnings are treated as errors by gcc
during build (a common practice)? Thanks if maintainer can take a
look.

relevant bug entry and complete bug logs:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63526
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Tuesday, 23 May 2023

Re: [gccsdk] libssl1.1.1 no longer builds

On 21 May, alan buckley <alan_baa@hotmail.com> wrote:
> Thanks Chris, that got libssl1.1.1 building, but then there was another build problem with c-ares. I was trying to get libcurl to build. I agree it would be better to use libssl3, do you know if there is a libcurl that could be built using libssl3?

libcurl3 has been updated to build 8.0.1. Also the dependencies have been
updated to depend on libssl3 instead of libssl1.1.1 and libcares instead of
c-ares.
To use libssl3 didn't required any changes to libcurl3.

Chris.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Sunday, 21 May 2023

Re: [gccsdk] libssl1.1.1 no longer builds

Thanks Chris, that got libssl1.1.1 building, but then there was another build problem with c-ares. I was trying to get libcurl to build. I agree it would be better to use libssl3, do you know if there is a libcurl that could be built using libssl3?

 

Thanks,

Alan

 

From: Chris Gransden
Sent: 13 May 2023 13:55
To: gcc@gccsdk.riscos.info
Subject: Re: [gccsdk] libssl1.1.1 no longer builds

 

In article
<DBBP189MB1434ABEFBC4561DCB3BC6BBEF07A9@DBBP189MB1434.EURP189.PROD.OUTLOOK.COM>,
   alan buckley <alan_baa@hotmail.com> wrote:
> I've just tried to use the autobuilder to build something that depends on libssl1.1.1. The build fails because it can't find the URLs in the setvars script. Does anyone know if there is a better url to use some other modification that will get it to build again?

libssl3 (currently 3.1.0) was recently added to the autobuilder so probably
best to use that. If you still need libssl1.1 this should build now.

Chris.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

 

Sunday, 14 May 2023

Re: [Rpcemu] Exreacting files 2

Hi Steve,

In article <02dd8da45a.MSPro@Marker.Dommel.be>,
<riscos@markerdesign.be> wrote:
> How do I maintain the file extensions in a Bootfile when copying
> Uniboot from http://www.riscos.com/ftp_space/generic/uniboot/index.htm
> to the RPCEmu on Ubuntu. All Obay, Boot,Runfiles and so on are turned
> in to plain text files and so on.

When working with zip archives, always extract files meant for use under
RISC OS *inside* a running RPCEmu.

As you have found, extracting them outside the emulator will make them
lose their file types.

That said, I'm puzzled why you would want to use these ancient files.
Wouldn't it be better to use the files provided by ROOL?

Regards,
Frank

--
Frank

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] Exreacting files 2

Hi to all,

Yet an other problem on which I get stuck, not being very experienced
at programming.


How do I maintain the file extensions in a Bootfile when copying
Uniboot from http://www.riscos.com/ftp_space/generic/uniboot/index.htm
to the RPCEmu on Ubuntu. All Obay, Boot,Runfiles and so on are turned
in to plain text files and so on.

What is the trick to extract files form a Zipfile and place them
inside RPCEmu HostFS on a Linux Ubintu machine?Steve

--
Thanks for all the help so far, Steve

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Saturday, 13 May 2023

Re: [gccsdk] libssl1.1.1 no longer builds

In article
<DBBP189MB1434ABEFBC4561DCB3BC6BBEF07A9@DBBP189MB1434.EURP189.PROD.OUTLOOK.COM>,
alan buckley <alan_baa@hotmail.com> wrote:
> I've just tried to use the autobuilder to build something that depends on libssl1.1.1. The build fails because it can't find the URLs in the setvars script. Does anyone know if there is a better url to use some other modification that will get it to build again?

libssl3 (currently 3.1.0) was recently added to the autobuilder so probably
best to use that. If you still need libssl1.1 this should build now.

Chris.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

[gccsdk] libssl1.1.1 no longer builds

I've just tried to use the autobuilder to build something that depends on libssl1.1.1. The build fails because it can't find the URLs in the setvars script. Does anyone know if there is a better url to use some other modification that will get it to build again?

 

Regards,

Alan

 

Saturday, 6 May 2023

Re: [Rpcemu] Full screen modepermanently ON

In article <4e8539a05a.MSPro@Marker.Dommel.be>,
<riscos@markerdesign.be> wrote:
> Hi Ralph,


> Thanks for answering! I hope it turns out to be a valuable insight!
> It's Chinese to me, but I have send it on the the shop ware I have
> bought the laptop. The owner is willing to help me out with setting up
> RPCEmu properly (for the wright price that is...).

> I will be looking for a key combination under RISC OS to swish the
> fullscreen on. If this is possible I can put this in a Obayfile to do
> this automatically

> Thanks again, Steve

I'm a little confused as to what/where you want this operation to happen,
but this is what I do.

On the Windows side.
Create a shortcut to the "RPCEmu-Recomplier.exe"

Hilight the shortcut and Click context menu Properties or (Ctrl+Alt for
the Key shortcut).

In the properties, on the left hand side, look for "Run:" and next to that
is a box with a down pointing arrowhead. \/

Click the arrow and select "Maximised"

Click "OK" and thereafter double click the shortcut to Run RPCEmu.

Dave

--

Dave Triffid

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Full screen modepermanently ON

Hi Ralph,


Thanks for answering! I hope it turns out to be a valuable insight!
It's Chinese to me, but I have send it on the the shop ware I have
bought the laptop. The owner is willing to help me out with setting up
RPCEmu properly (for the wright price that is...).

I will be looking for a key combination under RISC OS to swish the
fullscreen on. If this is possible I can put this in a Obayfile to do
this automatically


Thanks again, Steve




In message <20230430110525.763B2200CD@orac.inputplus.co.uk> you wrote:

> Hi Steve,

>> I'd like to get the "full screen mode" switched on permanently.
> ...
>> does anyone know on which level the "full screen mode" button is
>> handled?

> I'd assume collaboration between rpcemu and the X window manager.

> Have a look at xdotool(1). Something like

> xclock &
> xdotool search --sync --class xclock \
> windowstate --toggle FULLSCREEN

> might work. Or perhaps there's a keypress which can be sent to the
> window instead.



--
Regards, Steve


_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu