On Sunday 9 Feb 2025, at 18:37, Greg A. Woods wrote:
> I do think they belong with the definition of dev_t though, which I
> think means keep them where they are.
FWIW, I also raised the issue upstream:
https://github.com/gazebosim/gz-msgs/issues/484
If this can be somehow fixed there, that work
On Friday 7 Feb 2025, at 13:22, Greg A. Woods wrote:
> That was the point of my mentioning their history -- it's unlikely
> anyone is willing to risk change such long-standing system C code just
> to work around some non-C problems with one or a very few applications.
That was also the point of m
On Thursday 6 Feb 2025, at 18:01, Greg A. Woods wrote:
> At Thu, 6 Feb 2025 23:48:48 +0100, Anthony Mallet
> wrote: Subject: major/minor(3) macros
> conflict with regular code
> >
> > Do major(3) and minor(3) really need to be macros?
>
> What do you mean "need
Hi,
I have some code that defines these methods in a C++ class:
int32_t major() const
int32_t minor() const
(for the context: this is in protobuf generated code from a message
that has major/minor fields).
The generated code fails to compile because it conflicts with major(3)
macro and minor(
Hi,
I think rpcgen -M might be missing the generation of the 'foo_freeresult_N'
server procedure signature in the generated foo_svc.c program.
I'm not sure however, as I did not manage to find proper documentation
about this. The fact is that I have a rpcgen program that fails to compile
properly
On Monday 6 Dec 2021, at 21:40, Robert Elz wrote:
> I know this thread is largely dead by now
I still read it with interest :)
(BTW, in case someone did not notice, there is lib/56531)
On Monday 29 Nov 2021, at 20:38, Robert Elz wrote:
> | In addition, I just noticed that res_nquery(3) in
> | libc/resolv/res_query.c uses a similar buffer but of size
> | min(PACKETSZ, 1024). PACKETSZ seems to be 512 bytes only.
>
> That is as it shoukd be.
> PR tge huge stack array if yiu wa
On Monday 29 Nov 2021, at 00:05, Anthony Mallet wrote:
> 64k is not small, so I still believe it should be on the heap.
In addition, I just noticed that res_nquery(3) in
libc/resolv/res_query.c uses a similar buffer but of size
min(PACKETSZ, 1024). PACKETSZ seems to be 512 bytes only.
So
On Sunday 28 Nov 2021, at 17:30, Mouse wrote:
> > I think it's related to a DNS query, so it might be the max size of a
> > UDP packet? (then why not 65kB?)
>
> Because the max UDP packet size is 64k (well, 64k-1 - the length field
> is 16 bits long).
Yes, of course. I was temporarily confused .
Hi,
I have a multi-threaded program that segfault in getaddrinfo(3).
To make a long story short, this is the backtrace from gdb:
Thread 3 "" received signal SIGSEGV, Segmentation fault.
[Switching to LWP 14939 of process 14113]
0x7f7ff5d3af50 in res_queryN (
name=name@entry=0x7f7ff7e55cb0
10 matches
Mail list logo
