- Oct 19, 2023
-
-
- Oct 14, 2023
-
-
- Aug 21, 2023
-
-
- Jun 26, 2023
-
-
Ron Williams authored
-
- Jun 05, 2023
-
-
- Jun 01, 2023
-
-
Jeremy Soller authored
-
- May 29, 2023
-
-
Florian Meißner authored
-
- May 22, 2023
-
-
- May 11, 2023
-
-
-
Jeremy Soller authored
-
Jeremy Soller authored
-
- May 10, 2023
-
-
- May 09, 2023
-
-
- May 08, 2023
-
-
- May 06, 2023
-
-
Ron Williams authored
-
Jacob Lorentzon authored
-
Jacob Lorentzon authored
-
Jacob Lorentzon authored
-
Jacob Lorentzon authored
-
Jacob Lorentzon authored
-
Ron Williams authored
-
- Apr 15, 2023
-
-
David CARLIER authored
-
- Mar 27, 2023
-
-
David CARLIER authored
close #32
-
- Mar 26, 2023
-
-
David CARLIER authored
reallocarray introduction available on glibc 2.26. allocates an array of m*n elements but checking for overflow.
-
- Mar 24, 2023
-
-
David CARLIER authored
those functions differently than the strn* ones as they do not pad with zero to remaining bytes but guarantees a null terminator.
-
- Mar 22, 2023
-
-
David CARLIER authored
-
- Dec 17, 2022
-
-
Jeremy Soller authored
-
Jeremy Soller authored
-
- Jul 27, 2022
-
-
Nagy Tibor authored
-
- Nov 30, 2021
-
-
Jeremy Soller authored
-
- Mar 02, 2021
-
-
Jeremy Soller authored
-
Jeremy Soller authored
-
- Feb 23, 2021
-
-
Peter Limkilde Svendsen authored
-
- Jan 14, 2021
-
-
8tab authored
BufWriter has more capacity (8k vs 1k) and doesn't flush the stream after '\n'. That change helps to reduce the number of syscalls, especially when dealing with text files. Since BufWriter has a different way of getting number of pending elements than LineWriter - Pending trait was introduced to deal with that.
-
- Jan 05, 2021
- Jan 03, 2021
-
-
8tab authored
inner_scanf prematurely exited before parsing collected string
-
8tab authored
Instead of a single source of symbols, now linker keeps a list of DSO (former Library) objects with their own symbols map. That helps to process R_X86_64_COPY relocations correctly. For example, if 'a.out' executable with dependencies ['libstdc++.so', 'libc.so'] is being loaded and 'a.out' uses 'stdout' symbol from 'libc.so', its relocation process goes as follows: - linker processes relocation entry 'stdout' of type R_X86_64_GLOB_DAT from 'libc.so', - it goes through object list ['a.out', 'libstdc++.so', 'libc.so'] to find first object that exports 'stdout' symbol. The symbol is in 'a.out' with the value e.g. '0x404070', - linker sets 'stdout' symbol GOT entry in 'libc.so' to '0x404070', .... - linker processes relocation entry 'stdout' of type R_X86_64_COPY from 'a.out', - it goes through object list excluding 'a.out': ['libstdc++.so', 'libc.so']. The symbol is found in 'libc.so', - linker copies the 'stdout' symbol content from 'libc.so' to memory at address '0x404070' (in 'a.out' object). Objects are relocated in reverse order they were loaded. So in the example above, linker starts with relocating 'libc.so' and ends with 'a.out'. It is necessary e.g. when linking with 'libstdc++.so' - there are many relocations which symbols are found in 'libstdc++.so', so they need to be resolved before their contents are copied to 'a.out'. That also matches GNU ld.so behavior.
-