Unbelievably strange code in xterm.......UGHHHH !

Unbelievably strange code in xterm.......UGHHHH !

Post by Farooq Bu » Wed, 24 Jul 1991 05:27:01



I found the following gem in main.c (part of xterm):

main.c:         fileno(stderr) = i;
main.c:         fileno(stderr) = i;

What the hell does this do? I assume that fileno(stderr) is NOT an lvalue
so why is it being treated like one ? Is this a grand old UNIX trick that
I am somehow missing the point of ???

fmb

--
Standard High-Tech Disclaimer: NOTHING  in the above article has the slightest
relationship to reality. If any reality correspondences are found, please
notify me IMMEDIATELY. Any threats, abuse or stupidity of any kind is purely
UNintentional. These are MY Opinions NOT my employer's.

 
 
 

Unbelievably strange code in xterm.......UGHHHH !

Post by Blair P. Hought » Wed, 24 Jul 1991 13:49:20



>I found the following gem in main.c (part of xterm):
>main.c:         fileno(stderr) = i;
>main.c:         fileno(stderr) = i;
>What the hell does this do? I assume that fileno(stderr) is NOT an lvalue

Do this:

        egrep fileno /usr/include/*.h

for enlightment.

                                --Blair
                                  "That'll be two magnets
                                   and a pigeon's account."

 
 
 

Unbelievably strange code in xterm.......UGHHHH !

Post by Van Hooft P » Thu, 25 Jul 1991 00:15:07




>>I found the following gem in main.c (part of xterm):
>>main.c:         fileno(stderr) = i;
>>main.c:         fileno(stderr) = i;
>>What the hell does this do? I assume that fileno(stderr) is NOT an lvalue
>Do this:
>    egrep fileno /usr/include/*.h
>for enlightment.

Well, in fact fileno() _may_ be implemented as a macro, thus giving you
a legal lval, but it can be (and undoubtedly has been, somewhere) implemented
as a function _any_ time.

Therefore, for the sake of portability, you should see the light, and NOT
depend on the implementation of a function/macro :-)


Philips Research Labs, Eindhoven, the Netherlands

 
 
 

Unbelievably strange code in xterm.......UGHHHH !

Post by der Mou » Fri, 26 Jul 1991 18:21:07



> main.c:         fileno(stderr) = i;
> main.c:         fileno(stderr) = i;

This is a bug in xterm.  It depends on fileno() being implemented in
the "traditional" way, as a macro that happens to expand to an lvalue.
I haven't looked at the surrounding code, so I can't be sure what would
or wouldn't work as a replacement, but something like dup2(i,2) sounds
reasonable.

Of course, what xterm really needs is a rewrite, but that's another
story entirely....

                                        der Mouse

                        old: mcgill-vision!mouse

 
 
 

Unbelievably strange code in xterm.......UGHHHH !

Post by Dan Bernste » Sat, 27 Jul 1991 04:32:44



  [ on fileno(stderr) = i; in xterm's main.c ]

Quote:> I haven't looked at the surrounding code, so I can't be sure what would
> or wouldn't work as a replacement, but something like dup2(i,2) sounds
> reasonable.

The ``right'' solution is to have a global FILE *, initialized to
stderr, saying where errors should go. Presumably whoever wrote that
code in xterm thought that getting under stdio's skin was better than
having a global variable. (Current dogma holds that global variables are
bad things.) The problem is that it doesn't get rid of the variable; it
only hides it inside stdio where it's more difficult to manipulate.

---Dan

 
 
 

Unbelievably strange code in xterm.......UGHHHH !

Post by der Mou » Thu, 01 Aug 1991 19:10:14



[ on fileno(stderr) = i; in xterm's main.c ]

Quote:>> I haven't looked at the surrounding code, so I can't be sure what
>> would or wouldn't work as a replacement, but something like
>> dup2(i,2) sounds reasonable.
> The ``right'' solution is to have a global FILE *, initialized to
> stderr, saying where errors should go.

Not necessarily; it depends on why xterm wants to change the file
descriptor associated with stderr.  That's what I meant when I said I
hadn't looked at the code.

I have now looked at the context.  Since it is debugging code, having a
global FILE * as you suggest would not be satisfactory, if only because
there exist library routines which print things to stderr in
exceptional circumstances.  (They generally shouldn't, but that's
another matter.  xterm doesn't have access to the source for all of
them.)

What it wants is an fdreopen, or fredopen, or some such - something
combining freopen with fdopen.  (Hmmm, fredopen, is that something that
opens a fred? :-)

                                        der Mouse

                        old: mcgill-vision!mouse

 
 
 

1. Code fragments/plug-ins for solaris?

Is there anyway to write code fragments or plug-ins easily for Unix and/or
Solaris?

Essentially, I want to do what something like Photoshop does on my Mac (and
what I can do as code resources on my Mac).

A program looks in a directory for its plug-ins.  It plug-in contains a
fragment of code with a defined entry-point and constant interface.  The
plug-in however, is not fully linked or executable.

I want to be able to jump from the main program into the plug-ins according
to when their execution should be appropriate.

The shared object libraries come close... but I don't want the restriction
of having to link the main program with the plug-ins.

There is problably some deep kernel magic involved here, and or icky assembly
code...

If you know how I can do this, would you please mind sending me an email
describing how to do this (or better yet, source code!)?

Thanks.

-Dan

2. Cygwin - How do I use it?

3. ppp ughhhh..

4. need general ledger/bookkeeping software

5. ELM 2.4dev PL52 on AIX 3.1.5 ughhhh...

6. GLIB,GTK+ and GIMP

7. scp UNBELIEVABLY slow

8. Solaris 2.6 as a kind-of proxy server?

9. KMail 2.1: Unbelievably large message box

10. he'll be jumping near closed Geoffrey until his egg moves unbelievably

11. Fedora Core 2 Unbelievably slow

12. You Linux people are unbelievably stupid.