Linux-kernel mailing list archive 1999-20,: Re: sendmsg() arguments

# Re: sendmsg() arguments

Alex Belits (abelits@phobos.illtel.denver.co.us)
Sun, 16 May 1999 14:24:46 -0700 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Nils Vogels: "Re: EFS in 2.3.2 ???"
- Previous message: Jeff -: "block-major-xx"
- In reply to: kuznet@ms2.inr.ac.ru: "Re: sendmsg() arguments"

On Sun, 16 May 1999 kuznet@ms2.inr.ac.ru wrote:

> > involved, so its size is meaningless). However 2.2.x checks msg->msg_namelen
> > instead -- if it's nonzero, msg->msg_name is considered to be an address
> > even if it's NULL (and therefore error is returned). Why?
>
> Because I consider this as the only correct way.
>
> sendmsg() behaviour is not prescribed by any standards
> and this way is preferred, because:
>
> - it is error prone: bad msg_name and msg_namelen!=0 is
> usual application bug, showing malloc failure or memory corruption.

The only problem I have with that, is that msg_name=NULL was used in
some my program to indicate that there is no name, and it worked fine on
Linux 2.0.x, Solaris 2.x, FreeBSD 2.x-3.1, AIX 4.x and some others. Since
there was nothing about it in the standards, I assumed that it works in
more or less "natural" way ("NULL means nothing, but the size of
*possible* address can be nonzero, just like NULL can be assigned to the
pointer that is not void"). Even though there was neither memory
corruption, nor failed malloc() in my program, it was broken badly --
communication between two processes stopped working, and instead one
process was constantly getting errors from sendmsg() and going to the next
loop (it was a usual model with nonblocking communication in
select()/poll() loop). Program didn't check for EINVAL with known to be
valid arguments, so it wasn't even detectable without tracing.

I'm afraid that I was not the only person who did the same thing, and
what was supposed to catch application bugs, caught my possibly wrong but
justifiable guess.

> - it saves one statement if (name==NULL) namelen=0

This doesn't sound convincing.

>
> BTW some time ago recvfrom() behaved in the same manner,
> but broken way appeared to be described as valid in UNIX98,
> so that it was changed.

Maybe for consistency sake, sendmsg() can be made to match this?

    --
    Alex

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

- Next message: Nils Vogels: "Re: EFS in 2.3.2 ???"
- Previous message: Jeff -: "block-major-xx"
- In reply to: kuznet@ms2.inr.ac.ru: "Re: sendmsg() arguments"