Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

no sendmsg/recvmsg support #8383

Open
p5pRT opened this issue Mar 28, 2006 · 7 comments
Open

no sendmsg/recvmsg support #8383

p5pRT opened this issue Mar 28, 2006 · 7 comments

Comments

@p5pRT
Copy link

p5pRT commented Mar 28, 2006

Migrated from rt.perl.org#38808 (status was 'stalled')

Searchable as RT38808$

@p5pRT
Copy link
Author

p5pRT commented Mar 28, 2006

From @nwc10

Created by @nwc10

Neither the core nor Socket supports the socket functions sendmsg and recvmsg.

Perhaps they should, as without them it's not possible to get/send ancillary
data. Then again, this is sufficiently low level that it's likely to be hard
to pack/unpack it without platform specific knowledge of the C structures
involved.

Nicholas Clark

Perl Info

Flags:
    category=library
    severity=wishlist

Site configuration information for perl v5.8.3:

Configured by nick at Mon Jan 26 18:02:56 GMT 2004.

Summary of my perl5 (revision 5.0 version 8 subversion 3) configuration:
  Platform:
    osname=freebsd, osvers=4.7-stable, archname=i386-freebsd
    uname='freebsd plum.flirble.org 4.7-stable freebsd 4.7-stable #0: sun mar 23 18:33:06 gmt 2003 scot@pear.flirble.org:usrsrcsyscompileplum i386 '
    config_args='-Dcc=ccache gcc -Dld=gcc -Ubincompat5005 -Uinstallusrbinperl -Dcf_email=nick@ccl4.org -Dperladmin=nick@ccl4.org -Dinc_version_list=  -Dinc_version_list_init=0 -Doptimize=-Os -Dusethreads=n -Dinstallman1dir=none -Dinstallman3dir=none -Dprefix=~/Install/perl583 -de'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='ccache gcc', ccflags ='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -I/usr/local/include',
    optimize='-Os',
    cppflags='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -I/usr/local/include'
    ccversion='', gccversion='2.95.4 20020320 [FreeBSD]', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags ='-Wl,-E  -L/usr/local/lib'
    libpth=/usr/lib /usr/local/lib
    libs=-lbind -lgdbm -ldb -lm -lcrypt -lutil -lc
    perllibs=-lbind -lm -lcrypt -lutil -lc
    libc=, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-DPIC -fPIC', lddlflags='-shared  -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.3:
    /home/nick/Install/perl583/lib/5.8.3/i386-freebsd
    /home/nick/Install/perl583/lib/5.8.3
    /home/nick/Install/perl583/lib/site_perl/5.8.3/i386-freebsd
    /home/nick/Install/perl583/lib/site_perl/5.8.3
    /home/nick/Install/perl583/lib/site_perl
    .


Environment for perl v5.8.3:
    HOME=/home/nick
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/nick/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/home/nick/bin:/usr/local/sbin:/sbin:/usr/sbin
    PERL_BADLANG (unset)
    SHELL=/usr/local/bin/bash

@p5pRT
Copy link
Author

p5pRT commented Mar 28, 2006

From @gisle

Nicholas Clark (via RT) <perlbug-followup@​perl.org> writes​:

Perhaps they should, as without them it's not possible to get/send ancillary
data. Then again, this is sufficiently low level that it's likely to be hard
to pack/unpack it without platform specific knowledge of the C structures
involved.

I would suggest adding these to the POSIX module then.

--Gisle

@p5pRT
Copy link
Author

p5pRT commented Mar 28, 2006

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Mar 28, 2006

From shouldbedomo@mac.com

On 2006â??03â??28, at 17​:44, Gisle Aas wrote​:

I would suggest adding [sendmsg/recvmsg] to the POSIX module then.

AFAICT, everything currently in POSIX does correspond to something in
the IEEE 1003.1 standard. That's not true of sendmsg/recvmsg.

Maybe they snuck into the 2001 edition, of which I don't have a copy.
But, unless they have, I'd say POSIX was not the place for these two.
How about Socket?
--
Dominic Dunlop

@p5pRT
Copy link
Author

p5pRT commented Mar 28, 2006

From @gisle

Dominic Dunlop <shouldbedomo@​mac.com> writes​:

On 2006√03√28, at 17​:44, Gisle Aas wrote​:

I would suggest adding [sendmsg/recvmsg] to the POSIX module then.

AFAICT, everything currently in POSIX does correspond to something in
the IEEE 1003.1 standard. That's not true of sendmsg/recvmsg.

Maybe they snuck into the 2001 edition, of which I don't have a copy.

It is at least found in the 2004 edition​:

  http​://www.opengroup.org/onlinepubs/009695399/functions/sendmsg.html

But, unless they have, I'd say POSIX was not the place for these two.
How about Socket?

Socket is documented to be "just a translation of the C socket.h
file". All it does currently is to set up constants and functions for
packing and unpackings the structs defined in this header file. IMHO,
a function to pack/unpack 'struct msghdr' make sense here but not the
interface to the syscalls themselves.

--Gisle

@p5pRT
Copy link
Author

p5pRT commented Mar 29, 2006

From shouldbedomo@mac.com

On 2006–03–28, at 18​:45, Gisle Aas wrote​:

[sendmsg/recvmsg are] at least found in the 2004 edition [of IEEE
1003.1]​:

http​://www.opengroup.org/onlinepubs/009695399/functions/
sendmsg.html

Thanks. I stand corrected.
--
Dominic Dunlop

@p5pRT
Copy link
Author

p5pRT commented May 16, 2008

p5p@spam.wizbit.be - Status changed from 'open' to 'stalled'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants