bug-hurd
[Top][All Lists]
Advanced

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

Re: Bug#187391: PortingIssues sockaddr_un


From: Robert Millan
Subject: Re: Bug#187391: PortingIssues sockaddr_un
Date: Wed, 23 Apr 2003 17:36:58 +0200
User-agent: Mutt/1.5.4i

On Tue, Apr 22, 2003 at 02:47:01PM +0300, Ognyan Kulev wrote:
> 
> I didn't understand what lines you refer to.  I think "the second 
> line" is about
> 
> struct sockaddr_un sun = { AF_LOCAL, "/path/to/socket" };
> 
> This can be a bug in G++,

ok then. i'll try to find a test case outside glibc to prove it's
a gcc [1] bug, then submit a bug against gcc [1].

[1] as in gnu compiler collection (i could reproduce it with gcc, too)

> but it's bug in the program too because in 
> BSDs you have one more field: sun_len (before sun_family), and this 
> code will fail to compile too.

the code i was porting did have an #ifdef case for BSDs already. (i know
that's not an ellegant sollution, but see below..)

> The portable solution is to not use 
> such initialization because you aren't sure what fields are in struct 
> sockaddr_un.
> 
> >- the non-GLIBC example should use strncpy
> 
> There is a question whether we should include _portability_ issues in 
> our _porting_ page.  If we do, then we have to include example using 
> strncpy.

oh please please. we shouldn't introduce portability problems but we
aren't the "corageous knights" who go around fixing others' bugs just
for the fun of it.

I'd like to put up a clear bug report for gcc, then replace the lines in
PortingIssues with an explanation on the gcc bug and that such code should
remain intact. If noone opposes, i'll go for it.

-- 
Robert Millan

make: *** No rule to make target `war'.  Stop.

Another world is possible - Just say no to genocide




reply via email to

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