Linux-Development-Sys Digest #840, Volume #7 Wed, 10 May 00 05:13:10 EDT
Contents:
Re: Two really easy (I'm sure) questions (Erik Max Francis)
Re: Two really easy (I'm sure) questions ("Mark Graybill")
HELP: how to get si_fd from siginfo ("Boris Pran")
Re: Two really easy (I'm sure) questions ("Mark Graybill")
Driver programming: ioctls (=?iso-8859-1?Q?C=E9sar?= Espinosa)
Re: Two really easy (I'm sure) questions ("Mark Graybill")
Re: Two really easy (I'm sure) questions ("Peter T. Breuer")
Re: What cockheads you are ("Mark Graybill")
Re: What cockheads you are ("Bob Taylor")
----------------------------------------------------------------------------
From: Erik Max Francis <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development,comp.os.linux.development.apps
Subject: Re: Two really easy (I'm sure) questions
Date: Wed, 10 May 2000 00:04:16 -0700
Mark Graybill wrote:
> ANSI provides for the use of void main() (makes no provisions against
> it),
> and therefore compilers that do not support it are not fully ANSI
> compliant.
> Unless I see ANSI declaring otherwise, it is simply dogma.
You are mistaken. The ANSI/ISO Standard clearly states that the only
two legal prototypes for main are
int main(void);
and
int main(int argv, char *argv[]);
(There are variations which are legal, such as representing argv as a
char ** instead of a char *[], or changing the names of the arguments --
but these are C/C++ language issues, not true variations in prototypes.)
> I have also not observed 'undefined behavior' by any program that I've
> used
> void main() in. This is nonsense. It is simply a matter of opinion,
> not
> standard.
You do not apparently understand what "undefined behavior" means. It
means that the compiler can generate code which does anything it likes,
ranging from crashing to doing what you expect it to. "Undefined
behavior" means that you are writing a program which is not guaranteed
to work on other platform. That it might work the way you expect on
_your_ compiler (and version and operating system, etc.) is immaterial;
writing code that results in undefined behavior is a sign of bad
programming.
> All these 'standards' are mentioned, but they are a mystery - what are
> they?
> If a college professor says 'don't do something', is it a standard?
The international C++ Standard? Do you not know what these are? If
not, why are you talking about this subject?
See: ANSI/ISO C++ Standard, comp.lang.c++ FAQ. Also related are the
ANSI/ISO C Standard (from which C++ inherits its main behavior), and the
comp.lang.c FAQ, which takes care to discuss this issue.
> Now, let's get back to the original argument. The original poster
> described
> a simple program that was giving him difficulty. It was something
> like:
> void main(void){cout << "Hello world";} It was superfluous to the
> context
> of the thread to say it was bad practice to use void main(). Says
> who?
> Who cares?
It is not superfluous, it is wrong. It invokes undefined behavior. It
would be perfectly legitimate for an ANSI-conforming compiler, when fed
that program, to generate a program which, when run, cracks the root
password and reboots the machine, and while it's busy cracking the root
password, mailbombs the programmer's boss with one-line messages
reading, "Your employee does not know how to program in C++."
--
Erik Max Francis / [EMAIL PROTECTED] / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ The hour which gives us life begins to take it away.
\__/ Seneca
Alcyone Systems / http://www.alcyone.com/
Alcyone Systems, San Jose, California.
------------------------------
Reply-To: "Mark Graybill" <[EMAIL PROTECTED]>
From: "Mark Graybill" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development,comp.os.linux.development.apps
Subject: Re: Two really easy (I'm sure) questions
Date: Wed, 10 May 2000 07:22:51 GMT
Peter T. Breuer wrote in message <8f8h6a$gme$[EMAIL PROTECTED]>...
>Why? The explanation is above. Looks comprehensible to me! You are
>simply duplicating a descriptor. The code in the shell doesn't check
>whether it is an input descriptor or an output descriptor (it would need
>to try freopen in "r" mode to check, and that may not be sufficient).
The real question is if both works because of the design of the shells (on
purpose), or because its a fluke. If works because of design by standard,
then either one is 'legal.'
>: tell me why it is bad practice to use void main() instead of int main().
>
>Because the former is illegal and the latter is not. See ansi standard.
>(the return value is the exit code used by the shell).
I have referenced the standard (the copy I have), and all my references, and
none of them state it is illegal. I am downloading the current standard,
and will research it.
>: competition, and unwillingness to improve their skills - they hindered
team
>: dynamics. Team playing is a requirement in today's IT. The lack of
being a
>
>NO way.
>
>: good team player and willingness to improve your productivity are
qualities
>: used to weed out candidates.
>
>Pah. remind me not to work with you.
Correction, you would never work for me with that attitude. Teamwork is
mandatory due to the complexity of the projects I lead and/or participate
in, which is indicative of the trend in our industry. Going over budget
and/or over schedule because some punk who wants to be a lone wolf and/or
compete with everyone else on the project because it strokes his/her ego,
jeopardizes the success of the project.
>: my purpose (especially in a test program), and I've used 2<&1 because it
>: suited my purpose. If we should use 2>&1, tell us why. (I could really
>: care less which one I use - actually I may even have remembered it
>
>Could NOT care less. That does it. Anyone who can't get a negative right
>in speech is not to be trusted on a computer.
'NOT' and 'less' are both negatives, and your correction implies that I am
inclined to care more which one I use. "I could really care less" is
really inappropriate (should have used "I don't care", but I get a little
punchy late at night).
I don't, however, agree with your statement. Your insult was ineffective.
Besides, I have a portfolio of fortune 500 companies, 20 years experience,
and a sizeable income that would prove to be a formitable challenge to your
statement.
>: Again - please explain in technical terms WHY 2<&1 (and void main()) is
>: incorrect. I'm looking for solid technical reasons - not ethical
reasons.
>
>You got one above. It wouldn't work if the file were writable but not
>readable. Some logical problem?
You misunderstand my question. What is the technological consequence of
using 2<&1 instead of 2>&1. I understand what's happening with both, but I
want something tangible, like, "it works coincidentally because of a fluke,
and some shells may not support it"; or, "it has caused or could cause
uncertain behavior."
The clarity of the sentence fragment "Some logical problem?" is a little
fuzzy. Would you clarify it?
Perhaps you meant to say, "Do you have some problem with logic?" Not
sure... do you?
>: Or are all we are really doing is showing off? :)
>
>No. You are showing yourself UP.
Unless you are using some slang with a meaning I am unaware of, this is a
compliment. Somehow I don't think you intended it to be.
-Mark
------------------------------
From: "Boris Pran" <[EMAIL PROTECTED]>
Subject: HELP: how to get si_fd from siginfo
Date: Wed, 10 May 2000 09:22:09 +0200
I was trying to handle my serial port in asynchronous fashion by using
signals, but...
The port was open with
port_fd=open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_NONBLOCK);
and then I did
fcntl(port_fd, F_SETOWN, getpid());
fcntl(port_fd, F_SETFL, O_ASYNC);
fcntl(port_fd, F_SETSIG, SIGIO);
sigact.sa_handler = NULL;
sigact.sa_sigaction = &get_data;
sigact.sa_flags = SA_SIGINFO;
sigemptyset(&sigact.sa_mask);
sigaction(SIGIO, &sigact, NULL);
When character was received I found myself in
get_data(int sgnl, siginfo_t *siginf, void *contx)
just as expected
than I wanted to find out which fd caused the signal and I was surprised
siginf->si_signo returned 29 which is OK for SIGIO
siginf->si_code returned 0 which is NOT OK
siginf->si_fd returned -1071382528 or some similar number but never the
fd ????
It suppose to be fd of the file that sent signal if I understood
man pages corectly ???
OK, where did I go wrong - what did I miss ?
Any help will be appreciated. Thanks.
Boris
------------------------------
Reply-To: "Mark Graybill" <[EMAIL PROTECTED]>
From: "Mark Graybill" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development,comp.os.linux.development.apps
Subject: Re: Two really easy (I'm sure) questions
Date: Wed, 10 May 2000 07:46:27 GMT
Alan Donovan wrote in message <[EMAIL PROTECTED]>...
>Mark Graybill wrote:
>
>I didn't blindly place you in any category. As I'm sure you know, it's
>hard to judge from a single USENET post anything about the career of the
>person you are replying to. From what you wrote it sounded like you were
>a newbie to UNIX (you admit to being a shell newbie), so I wrote an
>appropriate response. My apologies if it was patronising, but no offence
>was intended.
Well, my deficit is that we didn't learn on unix workstations in college -
we had mainframes. The Air Force did train me for administrator on the AT&T
3B2 System V, but I remember very little - I even forgot all the hacking I
got in trouble for. Since then, if I had no need or desire to learn more
about the internals of a shell, I wouldn't. Perhaps if I am to be able to
contribute to the Linux project, I need to be.
I've noticed there's a lot of psychological issue processing on usenet, and
you can never tell what someone's intent is. Although I appreciate the
apology, no offense was taken.
>True, there are better languages, I have in fact had a play with one of
>them (on a 360) although for most purposes, for better or worse, those
>languages are dead now. Now you are telling me what I do and do not
>know. ;-)
Is that an IBM 360? I kind of liked writing code on them. I haven't worked
on one of them since my days at ASU.
>As I said, I was trying to be helpful based on the information
>available: you tell me you're new to Bourne shell, and you write one
>mistaken sentence (quoted below) about how the shell works. What would
>you have written in my place?
I have been guilty of misinterprettation and misunderstanding. I apologize
for my directness - no offense was intended.
>> >> Since the underlying code is a shell, I wouldn't think it would be
>> >> calling system calls for such things.
>
>> I am
>> really trying to prove a point to programmers that are great computer
>> scientists, but cling to practices they learned in school that they
cannot
>> ratify - and they hinder their growth as professionals. They aren't
willing
>> to let go of old dogma.
>
>Not at all. I like to understand exactly what is going on when I write
>code. I have seen enough people (most often without CS degrees) who will
>happily write "production" code laden with bugs arising from a
>misunderstanding of the system they are using, its abstractions and
>interfaces. Their programs just "happen to work" for long enough to sell
>the code.
I agree. If I was on a project that shipped shell scripts, I would be
inclined to master it first.
>IMHO understanding exactly what set of system calls (in fact all
>operations, e.g substitution, expansion, path search, redirection,
>terminal control) are invoked by the shell when you run the program "ls"
>is incredibly useful in being able to track down problems. It's no
>coincidence that this very question frequently appears in exam
>questions, tutorial books and even job interviews.
If I had Unix instead of mainframes in college, I'm sure it would have been
on an exam. However, unless they would ask the question in an administrator
interview, of the 50 or so technical interviews I've given, it's never been
asked or included on an electronic test (they only ask programming related
questions.) Since the shell is simply there as a tool for me to use, how I
use it is inconsequential as long as it works, unless it directly affects my
product or the system I'm using. If it fails to work on another Unix
system, then I would find out why and use the appropriate. Besides, I have
used visual tools long enough to easily forget. I could have simply
remembered it wrong.
The real question is, does it or could it have technical consequences, or is
it simply a matter of ethics or opinion which is 'legal?'
BTW, I recently tried it on HP-UX, OS/2, and NT, and they all support 2<&1.
I would be interesting to know why.
Best,
Mark
------------------------------
From: =?iso-8859-1?Q?C=E9sar?= Espinosa <[EMAIL PROTECTED]>
Subject: Driver programming: ioctls
Date: Wed, 10 May 2000 10:16:06 +0200
Hi all,
Does anybody know where I can find detailed informations about
ioctls?
Thanks,
C�sar
------------------------------
Reply-To: "Mark Graybill" <[EMAIL PROTECTED]>
From: "Mark Graybill" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development,comp.os.linux.development.apps
Subject: Re: Two really easy (I'm sure) questions
Date: Wed, 10 May 2000 08:41:44 GMT
Erik Max Francis wrote in message <[EMAIL PROTECTED]>...
>Mark Graybill wrote:
>
>> ANSI provides for the use of void main() (makes no provisions against
>> it),
>> and therefore compilers that do not support it are not fully ANSI
>> compliant.
>> Unless I see ANSI declaring otherwise, it is simply dogma.
>
>You are mistaken. The ANSI/ISO Standard clearly states that the only
>two legal prototypes for main are
>
> int main(void);
>
>and
>
> int main(int argv, char *argv[]);
Yes. I have found my references (including "The ANSI C Programming Language
2nd Edition" by Kernighan and Ritchie - the founders of C), to either be in
error or lacking specifics of types of main.
>(There are variations which are legal, such as representing argv as a
>char ** instead of a char *[], or changing the names of the arguments --
>but these are C/C++ language issues, not true variations in prototypes.)
>
>> I have also not observed 'undefined behavior' by any program that I've
>> used
>> void main() in. This is nonsense. It is simply a matter of opinion,
>> not
>> standard.
>
>You do not apparently understand what "undefined behavior" means. It
>means that the compiler can generate code which does anything it likes,
>ranging from crashing to doing what you expect it to. "Undefined
>behavior" means that you are writing a program which is not guaranteed
>to work on other platform.
I agree, no misunderstanding existed. When you've written C programs on
various Unix flavors, OS/2, all the Winblows, DOS, and CTOS (another Intel
based multitasking operating system), and don't recall erratic behavior,
it's not a matter of misunderstanding, but of qualification that the
behavior is defined. However, I understand the dangers of deviating from an
accepted standard, and I am a opponent of such deviation.
The behavior depends on how crt0 is written (or whatever the loader module
is), and wether using void main() instead of int main() causes a stack
problem (crt0 would pop the return code off the stack that didn't have a
symetrical push.) Even if it fails, fortunately, the process cleanup
performed by the OS should fix it. But don't get me wrong, I don't advocate
it. In this regard, the behavior potentially can be erratic, and hence,
undefined.
>That it might work the way you expect on
>_your_ compiler (and version and operating system, etc.) is immaterial;
>writing code that results in undefined behavior is a sign of bad
>programming.
Agreed. If it is not acceptable to the ANSI standard, then it shouldn't be
used.
>> All these 'standards' are mentioned, but they are a mystery - what are
>> they?
>> If a college professor says 'don't do something', is it a standard?
>
>The international C++ Standard? Do you not know what these are? If
>not, why are you talking about this subject?
You obvious didn't pay attention to the entire context of the post. I
declared that there was no proviso in the ANSI C standard. It is
unfortunate (and disconcerting) that my references failed to provide any
certain standard of main return type other than int and void. I should have
downloaded (purchased) the current standard before I impetuously made that
statement.
>See: ANSI/ISO C++ Standard, comp.lang.c++ FAQ. Also related are the
>ANSI/ISO C Standard (from which C++ inherits its main behavior), and the
>comp.lang.c FAQ, which takes care to discuss this issue.
>
>> Now, let's get back to the original argument. The original poster
>> described
>> a simple program that was giving him difficulty. It was something
>> like:
>> void main(void){cout << "Hello world";} It was superfluous to the
>> context
>> of the thread to say it was bad practice to use void main(). Says
>> who?
>> Who cares?
>
>It is not superfluous, it is wrong. It invokes undefined behavior.
Although I have yet to verify the ANSI standard and even though my
references are inconclusive, I have to now agree that it is not appropriate.
>It would be perfectly legitimate for an ANSI-conforming compiler, when fed
>that program, to generate a program which, when run, cracks the root
>password and reboots the machine, and while it's busy cracking the root
>password, mailbombs the programmer's boss with one-line messages
>reading, "Your employee does not know how to program in C++."
>
Is that 'perfectly legitimate' function in ANSI?
Read "The ANSI C Programming Language 2nd Edition" by Kernighan and Ritchie
(founders of C), or "The C/C++ Programmer's Bible" by Jamsa and Klander
(just to name a couple of books I still have on C), and post what the
material states about return types for main().
You will not find anything supporting your argument, and actually, the
latter book starts out using void main(), until it begins explaining
returning exit codes. Furthermore, none of my products uses void main(),
but I have used it for just screwing around and never have witnessed any
behavior inconsistent with that of programs with int main(). Also, I agree
with the discipline of following standards, and since I was pretty certain
ANSI wasn't limiting main()'s return type to int, I failed to find support
for the illegal use of void main().
Finally, it's sad so many feel they must insult, which is indicative of
their maturity.
-Mark
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development,comp.os.linux.development.apps
Subject: Re: Two really easy (I'm sure) questions
Date: 10 May 2000 08:39:55 GMT
In comp.os.linux.development Mark Graybill <[EMAIL PROTECTED]> wrote:
: Peter T. Breuer wrote in message <8f8h6a$gme$[EMAIL PROTECTED]>...
:>Why? The explanation is above. Looks comprehensible to me! You are
:>simply duplicating a descriptor. The code in the shell doesn't check
:>whether it is an input descriptor or an output descriptor (it would need
:>to try freopen in "r" mode to check, and that may not be sufficient).
: The real question is if both works because of the design of the shells (on
: purpose), or because its a fluke. If works because of design by standard,
: then either one is 'legal.'
It's simply undefined behaviour, and it works by fluke. It's obvious
_why_ it works once you realise that the syntax is hiding a call to
dup(2). You can test that theory by trying it on something on which
a dup of the descriptor wouldn't yield a writable result. I suggest
any file that is readable but not writable.
:>: tell me why it is bad practice to use void main() instead of int main().
:>
:>Because the former is illegal and the latter is not. See ansi standard.
:>(the return value is the exit code used by the shell).
: I have referenced the standard (the copy I have), and all my references, and
I believe you are mistaken here. It's a common bone to pick on comp.lang.c.
: none of them state it is illegal. I am downloading the current standard,
: and will research it.
:>: good team player and willingness to improve your productivity are qualities
:>: used to weed out candidates.
:>
:>Pah. remind me not to work with you.
: Correction, you would never work for me with that attitude. Teamwork is
And I wouldn't want to. Freedom is important to me. It seems you are
used to dealing with people you can browbeat.
:>: my purpose (especially in a test program), and I've used 2<&1 because it
:>: suited my purpose. If we should use 2>&1, tell us why. (I could really
:>: care less which one I use - actually I may even have remembered it
:>
:>Could NOT care less. That does it. Anyone who can't get a negative right
:>in speech is not to be trusted on a computer.
: 'NOT' and 'less' are both negatives, and your correction implies that I am
: inclined to care more which one I use. "I could really care less" is
: really inappropriate (should have used "I don't care", but I get a little
: punchy late at night).
You seem not to get it. "I could not care less .." is the expression.
Saying "I could care less .." means that you do care, whereas you mean
to say that you don't.
: I don't, however, agree with your statement. Your insult was ineffective.
: Besides, I have a portfolio of fortune 500 companies, 20 years experience,
: and a sizeable income that would prove to be a formitable challenge to your
: statement.
If money were proof of value ... tell that to all the starving russian
rocket scientists.
:>: Again - please explain in technical terms WHY 2<&1 (and void main()) is
:>: incorrect. I'm looking for solid technical reasons - not ethical reasons.
:>
:>You got one above. It wouldn't work if the file were writable but not
:>readable. Some logical problem?
: You misunderstand my question. What is the technological consequence of
: using 2<&1 instead of 2>&1. I understand what's happening with both, but I
See above. It won't work in some circumstances, and you're lucky it
works at all.
: want something tangible, like, "it works coincidentally because of a fluke,
: and some shells may not support it"; or, "it has caused or could cause
: uncertain behavior."
That's what I just said, no? I quote "It wouldn't work if the file were
writable but not readable".
: The clarity of the sentence fragment "Some logical problem?" is a little
: fuzzy. Would you clarify it?
Somehow I think you have done it yourself!
: Perhaps you meant to say, "Do you have some problem with logic?" Not
: sure... do you?
I meant to say that, and I did. The interrogation at the end marks an
elided "Is there ..." at the beginning in coloquial speech.
:>: Or are all we are really doing is showing off? :)
:>
:>No. You are showing yourself UP.
: Unless you are using some slang with a meaning I am unaware of, this is a
: compliment. Somehow I don't think you intended it to be.
Try dictionary. To "show someone up" is to reveal them as being
relatively handicapped. Well, who knows, perhaps this combination has a
different meaning in american english? I'm not hip on jive.
Peter
------------------------------
Reply-To: "Mark Graybill" <[EMAIL PROTECTED]>
From: "Mark Graybill" <[EMAIL PROTECTED]>
Subject: Re: What cockheads you are
Date: Wed, 10 May 2000 08:46:14 GMT
Kaz Kylheku wrote in message ...
>Are we to understand that you are propositioning the (largely male)
readership
>of the newsgroup to engage in fellatio?
It would apear so. Perhaps we should suggest he post on a news group
something like...just a minute, let me look for something... Ok, this looks
like it might work for him: alt.personals.gay
------------------------------
Reply-To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED] ("Bob Taylor")
Subject: Re: What cockheads you are
Date: Wed, 10 May 2000 00:50:37 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Kaz Kylheku) writes:
> On Wed, 10 May 2000 02:05:49 +1000, www.homepagewizard.com
> <[EMAIL PROTECTED]> wrote:
>>You cocksuckers couldn't afford a fucking windows environment....poor cunts
>>probably couldn't afford a mouse or a 500meg hard drive. fuck it would be a
>>cunt to live like you low life scum, and you have the nerve to call yourself
>>fucking developers......SUCK MY DICK you low life fuckwits.
>
> Are we to understand that you are propositioning the (largely male) readership
> of the newsgroup to engage in fellatio?
Nah. He is under the impression he lives in a penthouse. Whereas we
*know* he is living in a cesspool just by the stink of his mouth.
--
+----------------------------------------------------------------+
| Bob Taylor Email: [EMAIL PROTECTED] |
|----------------------------------------------------------------|
| [Concerning MSFT innovating their way out of a wet paper bag.] |
| "Maybe if it were a very very wet paper bag, but then they'd |
| face the insurmountable barrier of surface tension." |
| -- Geoffrey Tobin <[EMAIL PROTECTED]> |
+----------------------------------------------------------------+
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
