IRC channel logs

<youpi>damo22 : the “vm: Add missing locking” commit I have just pushed will probably with smp correctness

<damo22>youpi: it seems to be helping with UP thanks

<youpi>damo22: uh? locking does nothing on UP

<damo22>sneek: later tell youpi i think i had gnumach UP from unreleased, but when i compiled master it fixed it for me. see https://paste.debian.net/plainh/d33bded4 i built GCJ

<sneek>Will do.

<damo22>hi youpi, master fixed UP compared to unreleased

<damo22>i was able to compile gcc and gcj

<Pellescours>damo22: I think it's the revert that fixed UP

<youpi>the darnassus wiki is coming back, please some more patience :)

<sneek>youpi, you have 1 message!

<sneek>youpi, damo22 says: i think i had gnumach UP from unreleased, but when i compiled master it fixed it for me. see https://paste.debian.net/plainh/d33bded4 i built GCJ

<youpi>damo22: from unreleased?

<youpi>I upload gnumach debian packages to unstable, not unreleased

<youpi>good that you got gcc-6 built again, it's be good to have the source .dsc etc. so I can build&upload to unreleased, both on hurd-i386 and hurd-amd64

<youpi>the darnassus wiki is back :)

<Pellescours>youpi: in bits/dirents.h I can see that dirent.d_name is defined as "char d_name[1]", with a comment saying it’s actually longer

<youpi>yes it's dynamic

<Pellescours>do you know what define this file (gcc, glibc)? This definition of char[1] trigger compilation errors for coreutils 9.6 as it trigger the errer strict-flex-arrays

<youpi>it's glibc

<Pellescours>at lib/fts.c:235:43

<Pellescours>this line https://github.com/coreutils/gnulib/blob/master/lib/fts.c#L1463, calling this one https://github.com/coreutils/gnulib/blob/master/lib/fts.c#L235 and so here a is considered as char[1] so gcc correctly complains about the access to a[1] (and a[2])

<youpi>would it work better with [0] or [] ?

<Pellescours>testing with []

<youpi>AIUI __flexarr can be used along __glibc_c99_flexarr_available, see e.g. sysdeps/unix/sysv/linux/bits/socket.h

<youpi>probably you can fix d_name the same way

<Pellescours>with [] it worked, I will try to see __flexarr also

<Pellescours>youpi: I think in glibc we can just use __flexarr without guarding it like for linux/bits/socket.h, I saw some other places that uses __flexarr without the #ifdef

<Pellescours>and do I need copyright assignment for glibc if I want to make a patch for this file? I did it only for gnumach and hurd

<youpi>in public headers?

<youpi>you can put Signed-off-by to avoid a copyright assignment

<Pellescours>in locale/localeinfo.h it’s used

<Pellescours>and in sysdeps/unix/sysv/linux/sys/inotify.h also

<youpi>these are probably only compatible with gcc anyway

<youpi>better do it the clean way anyway

<Pellescours>ok, in misc/sys/sysdefs.h there is the definition of the macro and the __flexarr is always defined

<Pellescours>if it’s unsupported by the compiler it fall back to "[1]" and the __glibc_* is defined to 0

<youpi>ah __flexarr is always define

<youpi>then it will be fine to avoid the #ifdef indeed

<Pellescours>ah but this breaks perl building. perl does "if(len > sizeof(dirent->d_name) && sizeof(dirent->d_name) > PTRSIZE)"...

<youpi>Pellescours: perhaps you can instead #ifdef __glibc_c99_flexarr_available d_name [0] #else d_name[1]

<Pellescours>yes, but is it "legal" what perl does here (https://github.com/Perl/perl5/blob/blead/sv.c#L14148)?

<Pellescours>sizeof assumes that the arrays length is known at compile time, but does posix require d_name to be statically sized?

<youpi>The array d_name is of unspecified size

<youpi>I don't know if that means that it does necessarily have a size

<youpi>using [0] when it is known that it is allowed is stricly better than just using [1] always

<youpi>using [] means having to fight with all software that could want to sizeof() it just because most other OSes do set a size

<Pellescours>when I set [0] Perl built

<Pellescours>but I need to retest for gnulib with [0] then

<Pellescours>sad that people rather put arbitrary limit (PATH_MAX, …) to make their life easier. This make other people put strong assumption on the existence of theses limits that should not exists

<Pellescours>using [0] does not works for gnulib

<youpi>uh :/

<Pellescours>(re-checking that I properly did the modification)

<youpi> https://codesearch.debian.net/search?q=sizeof%5B%5E%28%5D*%5C%28%5B%5E%29%5D*%5Cbd_name&literal=0

<youpi>many results

<youpi>so making it [] is not really an option

<youpi>although most of these are probably just bogus :/

<youpi>(when using a flexarray)

<youpi>we might be better off with making it [255] like others

<Pellescours>sad, so the other solution is to do like for linux and put a high value

<youpi>there really is a maximum length here due to d_namlen being a char

<Pellescours>it’s explicitely said that size is unspecified but have a upper limit https://pubs.opengroup.org/onlinepubs/7908799/xsh/dirent.h.html

<Pellescours>my linux has d_name[256]

<Pellescours>the commit that added MACRO_BEGIN broke my cross-compilation of gnumach :/

<Pellescours>ah no nevermind

<Pellescours>it’s glibc that fails

<Pellescours>I need to investiguate but now (glibc master up to date) it fails to compile clock_gettime with error: implicit declaration of function 'MACRO_BEGIN' (TIME_VALUE_TO_64_TIMESPEC)

<Pellescours>Ah but it’s really linked to the commit with MACRO_BEGIN addition, I think it’s a missing #include. During the build of glibc, at the step of clock_gettime, it includes <mach/time_value.h> and now it uses the macro, but the macro is undefined (missing include I would say)

IRC channel logs

2025-02-13.log