[HelenOS-devel] Defense of HelUSB3 project

[Ondřej Hlavatý]

Hi everybody,

I completely forgot to do it during the hangout. Our project will be
publicly defended 16.3. at 13:03. More information can be found at [1].
If you want, you can come and help us :) It probably won't be much into
details of the USB stack and the implementation, it might be
interesting/fun though.

Good night,
Ondra


[1] http://www.ksi.mff.cuni.cz/sw-projekty/aktuality.html

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] What is wrong with restrict parameters?

[Ondřej Hlavatý]

Hi,

strictly speaking, couldn't you define "restrict" a macro in the same
way then? ;)

OH

On 15.11., Jiří Zárevúcky wrote:
> Hi,
> 
> the reason is that "restrict" wasn't a keyword before C99, so those headers
> couldn't be included in code written for C89. __restrict__ is non-standard,
> but that doesn't limit its usability in any way -- if you want to use a
> compiler that doesn't support it, you can just define __restrict__ to be an
> empty macro on the command line.
> 
> On Nov 15, 2017 10:00 AM, "Vojtech Horky"  wrote:
> 
> > Hello Jiri,
> >
> > I have noticed the following commit [1] where the restrict keyword was
> > replaced with __restrict__ in multiple headers. I was wondering what
> > is the reason for replacing C99 standard keyword with a proprietary
> > extension (though implemented both by GCC and clang)? I assume they
> > are equivalent, right?
> >
> > Thanks,
> > - Vojtech
> >
> >
> > [1] https://github.com/HelenOS/helenos/commit/
> > 0dd477996e38407057517d8fe2b97d416cd4e667
> >
> > ___
> > HelenOS-devel mailing list
> > HelenOS-devel@lists.modry.cz
> > http://lists.modry.cz/listinfo/helenos-devel
> >

> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Everyone please move to the git repository

[Ondřej Hlavatý]

Hello again,

just to inform others, it was solved it by updating python library
fastimport (to the development version, but I suppose my version was
just outdated).

It seems that the conversion script worked and our xhci branch is live:
https://github.com/helenos-xhci-team/helenos

We're sorry for dzejrou's karma, but for most of us this is a relief :)

Thanks for providing the script and info!
Ondra

On 13.11., Ondra Hlavatý wrote:
> Hi!
> 
> We would like to import our xhci branch, but the import currently fails
> somewhere inside bazaar. It happens both when I try to `git bzr clone`
> or just `git bzr import` our bazaar branch.
> 
> > 13:16:11 5000/11087 commits exported at 2742/minute 
> > 13:16:11 Skipping empty dir uspace/dist/dev in rev 
> > m.lombard...@gmail.com-20110904113058-trhdshrggn5s480c
> > bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 
> > 0xc5 in position 2: ordinal not in range(128)
> > 
> > Traceback (most recent call last):
> (... stacktrace removed ...)
> > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc5 in position 2: 
> > ordinal not in range(128)
> > 
> > bzr 2.7.0 on python 2.7.14 (Linux-4.13.11-1-ARCH-x86_64-with-glibc2.2.5)
> > arguments: ['/usr/bin/bzr', 'fast-export', '--plain', '--export-
> > marks=/home/ohlavaty/projects/xhci/.git/bzr/map/xhci-bzr', '--git-
> > branch=bzr/xhci', '/home/ohlavaty/projects/xhci/.git/bzr/repo/xhci']
> > plugins: bash_completion[2.7.0], bisect[1.1.0dev], changelog_merge[2.7.0],
> > etckeeper[unknown], fastimport[0.14.0dev], grep[2.7.0], gtk[0.104.0],
> > launchpad[2.7.0], netrc_credential_store[2.7.0], news_merge[2.7.0],
> > po_merge[2.7.0], qbzr[0.23.2], rewrite[0.6.4dev], stats[0.2.0dev],
> > weave_fmt[2.7.0]
> > encoding: 'utf-8', fsenc: 'UTF-8', lang: 'cs_CZ'
> > 
> > *** Bazaar has encountered an internal error.  This probably indicates a
> > bug in Bazaar.  You can help us fix it by filing a bug report at
> > https://bugs.launchpad.net/bzr/+filebug
> > including this traceback and a description of the problem.
> > ERROR:root:bzr export failed
> 
> Have you experienced this and if so, how did you solve it?
> 
> Thanks in advance,
> Ondra
> 
> On 12.11., Jan Vesely wrote:
> > nice.
> > 
> > Here's the script that I sued to concatenate svn and bzr history for
> > those who are interested:
> > 
> > #!/bin/sh
> > echo 4e161aaa908906c0ebaa75582bc7b5e529f2e785
> > 9035c5a039d04f61d696becf12fa6c74cbabe5ae  > .git/info/grafts
> > git filter-branch -f --tag-name-filter cat -- --all 
> > rm .git/info/grafts
> > 
> > 
> > bzr history was moved to git using git-bzr-ng.
> > 4e161aaa ("add '.bzr' to the ignore lists") is the second commit of bzr
> > history, after the initial import.
> > 
> > 9035c5a03 ("Bump version to 0.4.1 (Escalopino).") is the last commit of
> > svn history.
> > 
> > grafts are used to redirect local history. git filter branch then
> > rewrites it with that modification. Note that the rewritten hashes are
> > stable in a sense that bzr history can be forwarded (using git bzr
> > pull), and the shared commits between old and new will be identical
> > after running the concat script.
> > 
> > hope this helps if someone wants to convert their own branches,
> > Jan
> > 
> > On Sun, 2017-11-12 at 21:01 +0100, Jakub Jermář wrote:
> > > Hi all,
> > > 
> > > from now on please use:
> > > 
> > >   https://github.com/HelenOS/helenos
> > > 
> > > as the new mainline repository.
> > > 
> > > Even though the new repository contains a conversion of the old bzr and
> > > svn repositories, the old bzr repository should stay around in read-only
> > > mode at its current location.
> > > 
> > > We also plan to maintain a clone of this on helenos.org later.
> > > 
> > > Jakub
> > > 
> > > ___
> > > HelenOS-devel mailing list
> > > HelenOS-devel@lists.modry.cz
> > > http://lists.modry.cz/listinfo/helenos-devel
> 
> 
> 
> > ___
> > HelenOS-devel mailing list
> > HelenOS-devel@lists.modry.cz
> > http://lists.modry.cz/listinfo/helenos-devel
> 



> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel



signature.asc
Description: PGP signature
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Everyone please move to the git repository

[Ondřej Hlavatý]

On 13.11., Ondra Hlavatý wrote:
> > encoding: 'utf-8', fsenc: 'UTF-8', lang: 'cs_CZ'

Also, it happens both with LANG='en_US' and LANG='cs_CZ'.

O.

> 
> On 12.11., Jan Vesely wrote:
> > nice.
> > 
> > Here's the script that I sued to concatenate svn and bzr history for
> > those who are interested:
> > 
> > #!/bin/sh
> > echo 4e161aaa908906c0ebaa75582bc7b5e529f2e785
> > 9035c5a039d04f61d696becf12fa6c74cbabe5ae  > .git/info/grafts
> > git filter-branch -f --tag-name-filter cat -- --all 
> > rm .git/info/grafts
> > 
> > 
> > bzr history was moved to git using git-bzr-ng.
> > 4e161aaa ("add '.bzr' to the ignore lists") is the second commit of bzr
> > history, after the initial import.
> > 
> > 9035c5a03 ("Bump version to 0.4.1 (Escalopino).") is the last commit of
> > svn history.
> > 
> > grafts are used to redirect local history. git filter branch then
> > rewrites it with that modification. Note that the rewritten hashes are
> > stable in a sense that bzr history can be forwarded (using git bzr
> > pull), and the shared commits between old and new will be identical
> > after running the concat script.
> > 
> > hope this helps if someone wants to convert their own branches,
> > Jan
> > 
> > On Sun, 2017-11-12 at 21:01 +0100, Jakub Jermář wrote:
> > > Hi all,
> > > 
> > > from now on please use:
> > > 
> > >   https://github.com/HelenOS/helenos
> > > 
> > > as the new mainline repository.
> > > 
> > > Even though the new repository contains a conversion of the old bzr and
> > > svn repositories, the old bzr repository should stay around in read-only
> > > mode at its current location.
> > > 
> > > We also plan to maintain a clone of this on helenos.org later.
> > > 
> > > Jakub
> > > 
> > > ___
> > > HelenOS-devel mailing list
> > > HelenOS-devel@lists.modry.cz
> > > http://lists.modry.cz/listinfo/helenos-devel
> 
> 
> 
> > ___
> > HelenOS-devel mailing list
> > HelenOS-devel@lists.modry.cz
> > http://lists.modry.cz/listinfo/helenos-devel
> 



> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel



signature.asc
Description: PGP signature
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Everyone please move to the git repository

[Ondřej Hlavatý]

Hi!

We would like to import our xhci branch, but the import currently fails
somewhere inside bazaar. It happens both when I try to `git bzr clone`
or just `git bzr import` our bazaar branch.

> 13:16:11 5000/11087 commits exported at 2742/minute 
> 13:16:11 Skipping empty dir uspace/dist/dev in rev 
> m.lombard...@gmail.com-20110904113058-trhdshrggn5s480c
> bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 
> 0xc5 in position 2: ordinal not in range(128)
> 
> Traceback (most recent call last):
(... stacktrace removed ...)
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc5 in position 2: 
> ordinal not in range(128)
> 
> bzr 2.7.0 on python 2.7.14 (Linux-4.13.11-1-ARCH-x86_64-with-glibc2.2.5)
> arguments: ['/usr/bin/bzr', 'fast-export', '--plain', '--export-
>   marks=/home/ohlavaty/projects/xhci/.git/bzr/map/xhci-bzr', '--git-
>   branch=bzr/xhci', '/home/ohlavaty/projects/xhci/.git/bzr/repo/xhci']
> plugins: bash_completion[2.7.0], bisect[1.1.0dev], changelog_merge[2.7.0],
>   etckeeper[unknown], fastimport[0.14.0dev], grep[2.7.0], gtk[0.104.0],
>   launchpad[2.7.0], netrc_credential_store[2.7.0], news_merge[2.7.0],
>   po_merge[2.7.0], qbzr[0.23.2], rewrite[0.6.4dev], stats[0.2.0dev],
>   weave_fmt[2.7.0]
> encoding: 'utf-8', fsenc: 'UTF-8', lang: 'cs_CZ'
> 
> *** Bazaar has encountered an internal error.  This probably indicates a
>   bug in Bazaar.  You can help us fix it by filing a bug report at
>   https://bugs.launchpad.net/bzr/+filebug
>   including this traceback and a description of the problem.
> ERROR:root:bzr export failed

Have you experienced this and if so, how did you solve it?

Thanks in advance,
Ondra

On 12.11., Jan Vesely wrote:
> nice.
> 
> Here's the script that I sued to concatenate svn and bzr history for
> those who are interested:
> 
> #!/bin/sh
> echo 4e161aaa908906c0ebaa75582bc7b5e529f2e785
> 9035c5a039d04f61d696becf12fa6c74cbabe5ae  > .git/info/grafts
> git filter-branch -f --tag-name-filter cat -- --all 
> rm .git/info/grafts
> 
> 
> bzr history was moved to git using git-bzr-ng.
> 4e161aaa ("add '.bzr' to the ignore lists") is the second commit of bzr
> history, after the initial import.
> 
> 9035c5a03 ("Bump version to 0.4.1 (Escalopino).") is the last commit of
> svn history.
> 
> grafts are used to redirect local history. git filter branch then
> rewrites it with that modification. Note that the rewritten hashes are
> stable in a sense that bzr history can be forwarded (using git bzr
> pull), and the shared commits between old and new will be identical
> after running the concat script.
> 
> hope this helps if someone wants to convert their own branches,
> Jan
> 
> On Sun, 2017-11-12 at 21:01 +0100, Jakub Jermář wrote:
> > Hi all,
> > 
> > from now on please use:
> > 
> >   https://github.com/HelenOS/helenos
> > 
> > as the new mainline repository.
> > 
> > Even though the new repository contains a conversion of the old bzr and
> > svn repositories, the old bzr repository should stay around in read-only
> > mode at its current location.
> > 
> > We also plan to maintain a clone of this on helenos.org later.
> > 
> > Jakub
> > 
> > ___
> > HelenOS-devel mailing list
> > HelenOS-devel@lists.modry.cz
> > http://lists.modry.cz/listinfo/helenos-devel



> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel



signature.asc
Description: PGP signature
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] Deadlock while booting

[Ondřej Hlavatý]

Hi,

On 05.11., Jakub Jermář wrote:
> On 10/27/2017 12:08 AM, Ondřej Hlavatý wrote:
> > I started to experience deadlock while booting HelenOS. It does not
> > happen every time, and when I add some debug prints, the deadlock
> > disappears completely.
> > 
> > The issue starts at ps2mouse driver, which adds mouse function from its
> > device_add operation. This remote call goes all the way to fun_online,
> > in which it is holding the writelock (blocking other drivers) and,
> > because the function is exposed, probably waiting inside
> > loc_register_tree_function, respectively in loc_service_register.
> > 
> > Looking at this function, it seems to be very similar to what Jakub
> > Jermar describes at:
> > 
> > http://jakubsuniversalblog.blogspot.cz/2011/09/debugging-file-system-hang-using.html?q=deadlock
> > 
> > As far as I understand the issue, this shall not be the case - this is
> > the sender, not the receiver, and there is no cycle of messages waiting
> > for themselves. But after swapping the order of exch release and waiting
> > for answer, the deadlock no longer occurs.
> > 
> > Can someone please confirm, that the order there is correct?
> 
> I don't think that changing the mutual ordering of loc_exchange_end()
> and async_wait_for() will fix this on its own. See #700 for details.

Everything you wrote there makes sense to me.

> Btw, when you were testing your fix, did you change the order only in
> loc_service_register() or also in other places? I would be actually very
> surprised if this changed anything because in all the deadlocks for
> which we have some data in #700 (i.e. your .svg and my log files), the
> LOC_SERVICE_REGISTER was the second request, not the first. The first
> must have been LOC_SERVICE_ADD_TO_CAT. locsrv did not even start
> processing the second one.

Well, the deadlock was very randomly occuring, so it is possible that it
just didn't show up because of some timing issues of previous requests.
It often happened that the deadlock disappeared by adding a debug print
somewhere completely unrelated.

Also, it wasn't clear at all to me why it should fix the deadlock,
that's why I asked instead of sending patch.

OH

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

[HelenOS-devel] Deadlock while booting

[Ondřej Hlavatý]

Hi,

I started to experience deadlock while booting HelenOS. It does not
happen every time, and when I add some debug prints, the deadlock
disappears completely.

The issue starts at ps2mouse driver, which adds mouse function from its
device_add operation. This remote call goes all the way to fun_online,
in which it is holding the writelock (blocking other drivers) and,
because the function is exposed, probably waiting inside
loc_register_tree_function, respectively in loc_service_register.

Looking at this function, it seems to be very similar to what Jakub
Jermar describes at:

http://jakubsuniversalblog.blogspot.cz/2011/09/debugging-file-system-hang-using.html?q=deadlock

As far as I understand the issue, this shall not be the case - this is
the sender, not the receiver, and there is no cycle of messages waiting
for themselves. But after swapping the order of exch release and waiting
for answer, the deadlock no longer occurs.

Can someone please confirm, that the order there is correct?

Thanks,
Ondra Hlavatý

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] [MERGE] Do not use uninitialized variables

[Ondřej Hlavatý]

There are few of them, but this one is OK. The value is always
initialized, and apparantly GCC is able to prove it sometimes.

Actually, most of the warnings I get with -Og are false alarms. Only
very few of them are real. That's why I think we should rather
explicitly turn on the magic yet unknown option, than to specify
unnecessary default values to silence GCC. Or a least make
maybe-uninitialized onlu a warning.

What's even more strange, now I cannot reproduce it with -O3 neither.
But I'm pretty sure it was -O3. Also, I wasn't the first to notice this
behavior, Petr Mánek did (CCing him). Maybe he can add some details from
his side.

$ amd64-unknown-elf-gcc -v
Using built-in specs.
COLLECT_GCC=bin/amd64-unknown-elf-gcc
COLLECT_LTO_WRAPPER=/home/ohlavaty/.local/cross/amd64-unknown-elf/bin/../libexec/gcc/amd64-unknown-elf/7.1.0/lto-wrapper
Target: amd64-unknown-elf
Configured with: 
/home/ohlavaty/projects/helenos/xhci/amd64-unknown-elf/gcc-7.1.0/configure 
--target=amd64-unknown-elf 
--prefix=/home/ohlavaty/.local/cross//amd64-unknown-elf 
--program-prefix=amd64-unknown-elf- --with-gnu-as --with-gnu-ld --disable-nls 
--disable-threads --enable-languages=c,objc,c++,obj-c++ --disable-multilib 
--disable-libgcj --without-headers --disable-shared --enable-lto 
--disable-werror
Thread model: single
gcc version 7.1.0 (GCC) 

OH

On 20.10., Jiří Zárevúcky wrote:
> The weirdest part that as far as I can tell, those are legit bugs.
> 
> On my end, I get no warnings whatsoever. The whole build is clean.
> 
> On 20 October 2017 at 01:17, Ondřej Hlavatý <aear...@eideo.cz> wrote:
> > OK, this one is just too weird. It seems GCC turns off some heuristics.
> > It might be a better option to find out how to turn it back on on lower
> > optimization levels.
> >
> > See this (command taken from make output, optimization moved to the very
> > end):
> >
> > $ cd uspace/drv/bus/pci/pciintel
> > $ $CROSS_PREFIX/amd64-unknown-elf/bin/amd64-unknown-elf-gcc  
> > -I../../../../lib/c/include -I../../../../lib/c/arch/amd64/include 
> > -I../../../../../abi/include -imacros ../../../../../config.h 
> > -ffreestanding -fno-builtin -nostdlib -nostdinc -fexec-charset=UTF-8 
> > -finput-charset=UTF-8 -D__LE__ -Werror -fno-omit-frame-pointer 
> > -ffunction-sections -Wall -Wextra -Wno-clobbered -Wno-unused-parameter 
> > -Wmissing-prototypes -std=gnu99 -Werror-implicit-function-declaration 
> > -Wwrite-strings -pipe -mno-tls-direct-seg-refs -g 
> > -I../../../../lib/drv/include -c pci.c -o pci.o -O0
> >
> > $ $CROSS_PREFIX/amd64-unknown-elf/bin/amd64-unknown-elf-gcc  
> > -I../../../../lib/c/include -I../../../../lib/c/arch/amd64/include 
> > -I../../../../../abi/include -imacros ../../../../../config.h 
> > -ffreestanding -fno-builtin -nostdlib -nostdinc -fexec-charset=UTF-8 
> > -finput-charset=UTF-8 -D__LE__ -Werror -fno-omit-frame-pointer 
> > -ffunction-sections -Wall -Wextra -Wno-clobbered -Wno-unused-parameter 
> > -Wmissing-prototypes -std=gnu99 -Werror-implicit-function-declaration 
> > -Wwrite-strings -pipe -mno-tls-direct-seg-refs -g 
> > -I../../../../lib/drv/include -c pci.c -o pci.o -O1
> >
> > pci.c: In function 'pci_conf_write':
> > pci.c:322:7: error: 'val' may be used uninitialized in this function 
> > [-Werror=maybe-uninitialized]
> >val &= ~(0xffU << ((reg & 3) * 8));
> >^~
> > cc1: all warnings being treated as errors
> > $ $CROSS_PREFIX/amd64-unknown-elf/bin/amd64-unknown-elf-gcc  
> > -I../../../../lib/c/include -I../../../../lib/c/arch/amd64/include 
> > -I../../../../../abi/include -imacros ../../../../../config.h 
> > -ffreestanding -fno-builtin -nostdlib -nostdinc -fexec-charset=UTF-8 
> > -finput-charset=UTF-8 -D__LE__ -Werror -fno-omit-frame-pointer 
> > -ffunction-sections -Wall -Wextra -Wno-clobbered -Wno-unused-parameter 
> > -Wmissing-prototypes -std=gnu99 -Werror-implicit-function-declaration 
> > -Wwrite-strings -pipe -mno-tls-direct-seg-refs -g 
> > -I../../../../lib/drv/include -c pci.c -o pci.o -O2
> >
> > $ $CROSS_PREFIX/amd64-unknown-elf/bin/amd64-unknown-elf-gcc  
> > -I../../../../lib/c/include -I../../../../lib/c/arch/amd64/include 
> > -I../../../../../abi/include -imacros ../../../../../config.h 
> > -ffreestanding -fno-builtin -nostdlib -nostdinc -fexec-charset=UTF-8 
> > -finput-charset=UTF-8 -D__LE__ -Werror -fno-omit-frame-pointer 
> > -ffunction-sections -Wall -Wextra -Wno-clobbered -Wno-unused-parameter 
> > -Wmissing-prototypes -std=gnu99 -Werror-implicit-function-declaration 
> > -Wwrite-strings -pipe -mno-tls-direct-seg-refs -g 
> > -I../../../../lib/drv/include -c pci.c -o pci.o 

Re: [HelenOS-devel] [MERGE] Do not use uninitialized variables

[Ondřej Hlavatý]

Well, it seems that the patch is sufficient only when compiling with
-O3. There are a lot of other warnings with -Og. It is probably worth
checking them all (possibly with -O0) and fixing/muting them at once.

Shall I prepare that?

OH

On 19.10., Ondra Hlavatý wrote:
> Hi all,
> 
> When building current mainline with freshly downloaded toolchain, GCC
> 7.1.0 complains about uninitialized variables. First of them is real
> (extent.c), the second is not, but it's probably too hard for GCC to
> infer.
> 
> Hope you're enjoing the hangout.
> Ondra Hlavatý

> # Bazaar merge directive format 2 (Bazaar 0.90)
> # revision_id: aear...@eideo.cz-20171019203001-ou7e3ow0z1h52dlv
> # target_branch: bzr://bzr.helenos.org/mainline/
> # testament_sha1: 5343d00f1a73b4b8864f22d5e19dae0f155642cd
> # timestamp: 2017-10-19 22:32:34 +0200
> # base_revision_id: zarevucky.j...@gmail.com-20171018151058-\
> #   ndrkufle1quqodg8
> # 
> # Begin patch
> === modified file 'uspace/lib/ext4/src/extent.c'
> --- uspace/lib/ext4/src/extent.c  2017-05-11 22:07:09 +
> +++ uspace/lib/ext4/src/extent.c  2017-10-19 20:30:01 +
> @@ -374,7 +374,7 @@
>  int ext4_extent_find_block(ext4_inode_ref_t *inode_ref, uint32_t iblock,
>  uint32_t *fblock)
>  {
> - int rc;
> + int rc = EOK;
>   /* Compute bound defined by i-node size */
>   uint64_t inode_size =
>   ext4_inode_get_size(inode_ref->fs->superblock, inode_ref->inode);
> 
> === modified file 'uspace/lib/trackmod/xm.c'
> --- uspace/lib/trackmod/xm.c  2014-10-13 17:31:01 +
> +++ uspace/lib/trackmod/xm.c  2017-10-19 20:30:01 +
> @@ -288,7 +288,7 @@
>   size_t samples;
>   size_t instr_size;
>   size_t smp_size;
> - size_t smp_hdr_size;
> + size_t smp_hdr_size = 0; /* GCC false alarm on uninitialized */
>   ssize_t nread;
>   uint8_t ltype;
>   trackmod_sample_t *sample;
> 
> # Begin bundle
> IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWe8h8/IAAhpfrAAwUPf//17I
> lACwACAAAgoAUASu73TT2tb13oim3qnhJQgp4m1T0mnqemTVPyp+o9Sfoo9qn6oMh6jQbRBl
> GhGJpo0mkPU0A0ABKEBRoyCbRMTT1GjQAAaNGgAaaoCbKNAAGjQaA0AGg0ABJJNGmpgTET0n
> oENNI8pkaDQGgNGE5ypN3TW0+0R5HZU5WV9U0/YwFtIdsdkMEzXS50UmZKCSSkkO9B2beBJRTDBB
> fETXzctT0PJvAt9bQk9U2VMYCzRs2vIqiyYKGc07734syjxSqw1mJBlQLfHZxNdkb7RszqhmPmzY
> L+AbSq+tfe9BqrcUtO2E5Qwx5KxA6RX9ae6s2j4UjvnbmBv+Os3l0ewCIY0HDDAwyEwkwiQgTGkd
> KppsRtJPGLIgqLCIPGf4Hd+wIEgyM41hteE6Rc3XdQUl7SltqQ4ZMpgvzIFuLoRaG/aXCyu7yFNq
> EKwVI2HxRJwt7cSbcSIBfIUyLiwFZAzLDzWjgByvVSmxSDIDpMtldhLoyjaTq6dDxziYCQpNxcUA
> UmyadFcQgM8Z7FprqSghIN+hLJSmhwAVsxF1ZCBRZcsz0BszFVp0V3idomXU0lZuwRhYSLg5lRbT
> W7moCZEk9rTjBzCsXpFIt0BT6MD1DVZbXkFyiBWWCnyI54CE77CwZkiS11pEdNQSZ9rUQi5ixt7i
> 64JiBZkBTqzC4Jg6TLDgFBZTAPaHSnVODxBYzGXDRyohYsvMQDPpKyV8nSMUH2OMlu5QxVezVOfk
> esUalyPYFiraTEDjpdSVy1tQiCiFjKLLJQmGMRRoBdQOLBBJOzsPY1PqDbF8jGdJengFEu5nHMKP
> qMpAM6leHOdcNhXTspYxNSYw+10EcO1dTVZMHrtxMY9/O9LSoU4INE9QQOOGNnFjaK3tget7SInN
> hFFtpv6sEqdEmXGoi1DjkG8fSdheYa7pWaRVLPn2SIKw5mfxklL99FMvbWEwM8SlnW9XAX9pBdBP
> CTGrcaJ5HvLTTl3vWgrAqphfE19OB3lZ2GM3Bh1haia+KDOdA/bncX4a37tDPd+kHOz3Qzsq5NMK
> gYRJgaCNcF2Fd9p/ZALzoRjx8yPWbpRh0YHXcS9vdldGpiZcTeSFqvaSEpYsRWHtWOIErYBVHnLk
> d50omtMjGwvR7xnjEm9wyrjQiRA7yh1mKrW0TzI8kPquqJX+f63Yw6UYIZBzRHMsvoPiQ8KfhJXo
> nm4zwkKW2on1O9iYueSgChEjQpNc3OMLUwz8dK4w8C3g57O0DZ4LcruCthUY2ghjK4cZFH9pIacG
> Q4CUEOVNfQ4ir74wNI0u3hBVDuZZf16C7erepZMURR2SnJFC63Kcz2gZfACtU6mGAWXai4Y9Tr0K
> F2AcqItgRvWZXPJlttKHEhUeCwpFWVS1yoITAzidBNU/qjVQYOVJFGlA4PZQELCWmQgClk6RXJCP
> zSKkCwKKItkBRz3m+QeRAzUxglsnxIgeF29VP4LNstLNyukyIpcZCySKtRjByqAgrj3nia6Dnjyb
> MkajQmgcewDuAbNsVYiePp6YwfxdyRThQkO8h8/I

> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

[HelenOS-devel] [MERGE] Do not use uninitialized variables

[Ondřej Hlavatý]

Hi all,

When building current mainline with freshly downloaded toolchain, GCC
7.1.0 complains about uninitialized variables. First of them is real
(extent.c), the second is not, but it's probably too hard for GCC to
infer.

Hope you're enjoing the hangout.
Ondra Hlavatý
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: aear...@eideo.cz-20171019203001-ou7e3ow0z1h52dlv
# target_branch: bzr://bzr.helenos.org/mainline/
# testament_sha1: 5343d00f1a73b4b8864f22d5e19dae0f155642cd
# timestamp: 2017-10-19 22:32:34 +0200
# base_revision_id: zarevucky.j...@gmail.com-20171018151058-\
#   ndrkufle1quqodg8
# 
# Begin patch
=== modified file 'uspace/lib/ext4/src/extent.c'
--- uspace/lib/ext4/src/extent.c	2017-05-11 22:07:09 +
+++ uspace/lib/ext4/src/extent.c	2017-10-19 20:30:01 +
@@ -374,7 +374,7 @@
 int ext4_extent_find_block(ext4_inode_ref_t *inode_ref, uint32_t iblock,
 uint32_t *fblock)
 {
-	int rc;
+	int rc = EOK;
 	/* Compute bound defined by i-node size */
 	uint64_t inode_size =
 	ext4_inode_get_size(inode_ref->fs->superblock, inode_ref->inode);

=== modified file 'uspace/lib/trackmod/xm.c'
--- uspace/lib/trackmod/xm.c	2014-10-13 17:31:01 +
+++ uspace/lib/trackmod/xm.c	2017-10-19 20:30:01 +
@@ -288,7 +288,7 @@
 	size_t samples;
 	size_t instr_size;
 	size_t smp_size;
-	size_t smp_hdr_size;
+	size_t smp_hdr_size = 0; /* GCC false alarm on uninitialized */
 	ssize_t nread;
 	uint8_t ltype;
 	trackmod_sample_t *sample;

# Begin bundle
IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWe8h8/IAAhpfrAAwUPf//17I
lACwACAAAgoAUASu73TT2tb13oim3qnhJQgp4m1T0mnqemTVPyp+o9Sfoo9qn6oMh6jQbRBl
GhGJpo0mkPU0A0ABKEBRoyCbRMTT1GjQAAaNGgAaaoCbKNAAGjQaA0AGg0ABJJNGmpgTET0n
oENNI8pkaDQGgNGE5ypN3TW0+0R5HZU5WV9U0/YwFtIdsdkMEzXS50UmZKCSSkkO9B2beBJRTDBB
fETXzctT0PJvAt9bQk9U2VMYCzRs2vIqiyYKGc07734syjxSqw1mJBlQLfHZxNdkb7RszqhmPmzY
L+AbSq+tfe9BqrcUtO2E5Qwx5KxA6RX9ae6s2j4UjvnbmBv+Os3l0ewCIY0HDDAwyEwkwiQgTGkd
KppsRtJPGLIgqLCIPGf4Hd+wIEgyM41hteE6Rc3XdQUl7SltqQ4ZMpgvzIFuLoRaG/aXCyu7yFNq
EKwVI2HxRJwt7cSbcSIBfIUyLiwFZAzLDzWjgByvVSmxSDIDpMtldhLoyjaTq6dDxziYCQpNxcUA
UmyadFcQgM8Z7FprqSghIN+hLJSmhwAVsxF1ZCBRZcsz0BszFVp0V3idomXU0lZuwRhYSLg5lRbT
W7moCZEk9rTjBzCsXpFIt0BT6MD1DVZbXkFyiBWWCnyI54CE77CwZkiS11pEdNQSZ9rUQi5ixt7i
64JiBZkBTqzC4Jg6TLDgFBZTAPaHSnVODxBYzGXDRyohYsvMQDPpKyV8nSMUH2OMlu5QxVezVOfk
esUalyPYFiraTEDjpdSVy1tQiCiFjKLLJQmGMRRoBdQOLBBJOzsPY1PqDbF8jGdJengFEu5nHMKP
qMpAM6leHOdcNhXTspYxNSYw+10EcO1dTVZMHrtxMY9/O9LSoU4INE9QQOOGNnFjaK3tget7SInN
hFFtpv6sEqdEmXGoi1DjkG8fSdheYa7pWaRVLPn2SIKw5mfxklL99FMvbWEwM8SlnW9XAX9pBdBP
CTGrcaJ5HvLTTl3vWgrAqphfE19OB3lZ2GM3Bh1haia+KDOdA/bncX4a37tDPd+kHOz3Qzsq5NMK
gYRJgaCNcF2Fd9p/ZALzoRjx8yPWbpRh0YHXcS9vdldGpiZcTeSFqvaSEpYsRWHtWOIErYBVHnLk
d50omtMjGwvR7xnjEm9wyrjQiRA7yh1mKrW0TzI8kPquqJX+f63Yw6UYIZBzRHMsvoPiQ8KfhJXo
nm4zwkKW2on1O9iYueSgChEjQpNc3OMLUwz8dK4w8C3g57O0DZ4LcruCthUY2ghjK4cZFH9pIacG
Q4CUEOVNfQ4ir74wNI0u3hBVDuZZf16C7erepZMURR2SnJFC63Kcz2gZfACtU6mGAWXai4Y9Tr0K
F2AcqItgRvWZXPJlttKHEhUeCwpFWVS1yoITAzidBNU/qjVQYOVJFGlA4PZQELCWmQgClk6RXJCP
zSKkCwKKItkBRz3m+QeRAzUxglsnxIgeF29VP4LNstLNyukyIpcZCySKtRjByqAgrj3nia6Dnjyb
MkajQmgcewDuAbNsVYiePp6YwfxdyRThQkO8h8/I
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel