bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH rust-libc] i386-gnu: Add GNU/Hurd os


From: Samuel Thibault
Subject: Re: [PATCH rust-libc] i386-gnu: Add GNU/Hurd os
Date: Mon, 10 Jul 2023 21:57:24 +0200
User-agent: NeoMutt/20170609 (1.8.3)

Sergey Bugaev, le lun. 10 juil. 2023 12:51:15 +0300, a ecrit:
> On Sun, Jul 9, 2023 at 1:06 PM Damien Zammit <damien@zamaudio.com> wrote:
> > diff --git a/src/unix/hurd/mod.rs b/src/unix/hurd/mod.rs
> > new file mode 100644
> > index 000000000..676ea2515
> > --- /dev/null
> > +++ b/src/unix/hurd/mod.rs
> > @@ -0,0 +1,2626 @@
> > +//! Definitions for GNU/Hurd i386
> 
> Should it be in an arch-specific file then, and not just src/unix/hurd/mod.rs?

Or use 

#[cfg(target_pointer_width = "64")]
#[cfg(target_pointer_width = "32")]

like Linux does.

I'd say for now we don't need to care, and just assume Hurd = Hurd-32
for now for simplicity.

> > +pub const _AIO_H: u32 = 1;
> > +pub const _FEATURES_H: u32 = 1;
> 
> Do we really want to export the header guard macros? :)

No we don't :)

> Perhaps dropping everything that starts with an underscore would be a
> good approximation of which definitions should be skipped.

For a start,  yes.

> > +pub const _DEFAULT_SOURCE: u32 = 1;
> 
> This was not built with _GNU_SOURCE, was it? Should it be?
> 
> My understanding is that _GNU_SOURCE and other guards are mostly
> useful to avoid cluttering the "user's namespace" with additional
> definitions that could conflict with the user's own definitions. This
> is not a concern for Rust, so we might as well export everything.

Possibly, indeed. Although for our current target (getting to bootstrap
rust at all), we probably don't need GNU symbols, so better avoid that
for now to avoid getting overflown with various errors for whatever
reason.

> What about symbol versioning?

I'd say let's not care for now :)

Samuel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]