Date: Wed, 22 Aug 2001 05:50:02 -0700 (PDT) From: Peter Pentchev <roam@ringlet.net> To: freebsd-ports@FreeBSD.org Subject: Re: ports/29934: [PATCH] scsh fails to compile Message-ID: <200108221250.f7MCo2N59209@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR ports/29934; it has been noted by GNATS. From: Peter Pentchev <roam@ringlet.net> To: freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: ports/29934: [PATCH] scsh fails to compile Date: Wed, 22 Aug 2001 15:43:15 +0300 Just to get this into the audit trail.. G'luck, Peter -- This sentence claims to be an Epimenides paradox, but it is lying. ----- Forwarded message from Evan Sarmiento <ems@open-root.org> ----- From: Evan Sarmiento <ems@open-root.org> Date: Wed, 22 Aug 2001 07:29:21 -0400 To: Peter Pentchev <roam@ringlet.net> Subject: Re: ports/29934: [PATCH] scsh fails to compile In-Reply-To: <20010822141501.D12936@ringworld.oblivion.bg> Hey, It actually does work. I was using scsh on my laptop that runs -CURRENT. Was using open write and read from scsh too, but I will contact the developers as well and use fdopen. Thanks a lot, Evan Peter Pentchev writes: > On Wed, Aug 22, 2001 at 07:09:12AM -0400, Evan Sarmiento wrote: > > Hey, > > > > I agree with you -- there probably is a better way to do this. But, with this patch, > > scsh compiled. It might be a good short-time solution? > > > > Whatever you feel is best, > > Sure it would compile; but does it work? Any code which calls > setfileno() would certainly fail to change the underlying file > descriptor of the referenced file; this would most probably cause > the program to fail in subtle, untraceable ways ;) > > I don't think that there is a 'quick' solution :( > The best you could do is send a bug report to the scsh developers, > and point out to them that fileno(FILE *) is not required to be > an lvalue by any standards, so an assignment to fileno(fs) is > not really guaranteed to work. The best way to do it would be > to use fdopen(3), if available (and it is available on most > recent releases of most OS's). > > G'luck, > Peter > > -- > If this sentence didn't exist, somebody would have invented it. > > > Peter Pentchev writes: > > > On Tue, Aug 21, 2001 at 02:32:30PM -0700, Evan Sarmiento wrote: > > > > > > > > >Number: 29934 > > > > >Category: ports > > > > >Synopsis: [PATCH] scsh fails to compile > > > > >Originator: Evan Sarmiento > > > > >Release: 5.0 > > > > >Organization: > > > > >Environment: > > > > FreeBSD teqnix.sekt7.org 5.0-CURRENT FreeBSD 5.0-CURRENT #2: Sun Aug 19 08:53:54 EDT 2001 kaworu@teqnix.sekt7.org:/usr/src/sys/compile/TEQNIX i386 > > > > >Description: > > > > When compiling, gcc complains because fileno(fs) = fd should be fd = fileno(fs) > > > > > > I don't think this is correct. The name of the function is 'setfileno()', > > > which seems to imply that the function really wants to change the fileno > > > of the FILE structure - that is, it wants to tweak the FILE structure > > > internals. > > > > > > The patch you are proposing would break the function's semantics - > > > the function would turn out to be a no-op, not changing the FILE structure > > > in any way. > > > > > > A more correct patch would be to change the application so that it does > > > not fumble inside the FILE structure. I don't really see ANY reason > > > that an app would want to change a FILE structure's file descriptor > > > *within the structure*, keeping all other fields in some inconsistent > > > state referring to the *old* file descriptor, instead of simply calling > > > the well-documented and standardized fdopen() stdio function. > > > > > > Unfortunately, I do not have the time to look at the scsh sources > > > right now, so I cannot see what would the correct fix be. However, > > > it is most certainly NOT correct for scsh to muck the FILE structure > > > internals - you are most probably seeing a problem because in -current, > > > the FILE internals were changed in a way that kept stdio completely > > > standards-compliant, made it somewhat more efficient, esp. WRT threads, > > > and as a side effect exposed such "smart" programs trying to poke their > > > fingers where they can only get burnt. -- ----------------------------------- Evan Sarmiento | www.open-root.org ems@sekt7.org | www.sekt7.org/~ems/ ----------------------------------- ----- End forwarded message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108221250.f7MCo2N59209>