* functions to determine dementions of console?
@ 2004-05-23 23:05 ameer armaly
2004-05-24 2:09 ` Glynn Clements
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: ameer armaly @ 2004-05-23 23:05 UTC (permalink / raw)
To: linux-c-programming
Hi all.
I was wondering if there are a set of functions/system calles to let me
know what someone's set their tty length and heighth too? I do this
because I don't want to presume 80x25 in case someone's got it set
otherwise.
Ameer
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: functions to determine dementions of console?
2004-05-23 23:05 functions to determine dementions of console? ameer armaly
@ 2004-05-24 2:09 ` Glynn Clements
2004-05-26 14:41 ` Christoph Bussenius
2004-05-30 19:12 ` J.
2 siblings, 0 replies; 16+ messages in thread
From: Glynn Clements @ 2004-05-24 2:09 UTC (permalink / raw)
To: ameer armaly; +Cc: linux-c-programming
ameer armaly wrote:
> I was wondering if there are a set of functions/system calles to let me
> know what someone's set their tty length and heighth too? I do this
> because I don't want to presume 80x25 in case someone's got it set
> otherwise.
There are two options:
1. Ask the kernel:
#include <sys/ioctl.h>
...
struct winsize ws;
int rows, cols;
ioctl(STDIN_FILENO, TIOCGWINSZ, &ws);
rows = ws.ws_row;
cols = ws.ws_col;
If the terminal size changes (e.g. resizing an xterm), the process
will receive SIGWINCH.
However, this requires that the kernel actually knows what the
terminal's dimensions are. That is likely to be the case for emulators
(e.g. xterm, telnet) and possibly for the Linux console, but not
necessarily for hardware terminals (e.g. a vt220 connected to a serial
port).
2. Examine the termcap/terminfo entry for $TERM.
#include <curses.h>
#include <term.h>
...
int rows, cols;
setupterm(NULL, 1, NULL);
/* lines and columns are global variables defined by curses */
rows = lines;
cols = columns;
According to the curs_terminfo manpage:
> The terminfo variables lines and
> columns are initialized by setupterm as follows: If
> use_env(FALSE) has been called, values for lines and
> columns specified in terminfo are used. Otherwise, if the
> environment variables LINES and COLUMNS exist, their val
> ues are used. If these environment variables do not exist
> and the program is running in a window, the current window
> size is used. Otherwise, if the environment variables do
> not exist, the values for lines and columns specified in
> the terminfo database are used.
--
Glynn Clements <glynn.clements@virgin.net>
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: functions to determine dementions of console?
2004-05-23 23:05 functions to determine dementions of console? ameer armaly
2004-05-24 2:09 ` Glynn Clements
@ 2004-05-26 14:41 ` Christoph Bussenius
2004-05-30 19:12 ` J.
2 siblings, 0 replies; 16+ messages in thread
From: Christoph Bussenius @ 2004-05-26 14:41 UTC (permalink / raw)
To: linux-c-programming
On Sun, May 23, 2004 at 07:05:07PM -0400, ameer armaly wrote:
> I was wondering if there are a set of functions/system calles to let me
> know what someone's set their tty length and heighth too? I do this
> because I don't want to presume 80x25 in case someone's got it set
> otherwise.
To quote vcs(4):
/dev/vcs[1-63] are character devices for virtual console terminals,
they have major number 7 and minor number 1 to 63, usually mode 0644
and owner root.tty. /dev/vcsa[0-63] are the same, but including
attributes, and prefixed with four bytes giving the screen dimensions
and cursor position: lines, columns, x, y. (x = y = 0 at the top left
corner of the screen.)
Regards,
Christoph
--
``There's no dark side of the moon, really
Matter of fact, it's all dark''
--Pink Floyd
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: functions to determine dementions of console?
2004-05-23 23:05 functions to determine dementions of console? ameer armaly
2004-05-24 2:09 ` Glynn Clements
2004-05-26 14:41 ` Christoph Bussenius
@ 2004-05-30 19:12 ` J.
2004-05-30 20:35 ` Micha Feigin
2 siblings, 1 reply; 16+ messages in thread
From: J. @ 2004-05-30 19:12 UTC (permalink / raw)
To: linux-c-programming; +Cc: ameer armaly
On Sun, 23 May 2004, ameer armaly wrote:
> Hi all.
> I was wondering if there are a set of functions/system calles to let me
> know what someone's set their tty length and heighth too? I do this
> because I don't want to presume 80x25 in case someone's got it set
> otherwise.
>
> Ameer
on the console the command `stty -a` will print:
speed 9600 baud; rows 33; columns 89; line = 0;
....
....
etc..
For a c program have a look at the term manpage and use the settings from
'terminfo'
#include <stdio.h>
#include <term.h>
#include <ncurses.h>
int main(void) {
int num_rows = 0, num_columns = 0;
setupterm(NULL, fileno(stdout), (int *)0);
num_rows = tigetnum("lines");
num_columns = tigetnum("cols");
printf("terminal:\ncolumns: %d\nrows %d\n", num_columns, num_rows);
return 0;
}
etc.....
G00dlUcK.....
Jeroen Reynders.
--
http://www.xs4all.nl/~winnetou/
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: functions to determine dementions of console?
2004-05-30 19:12 ` J.
@ 2004-05-30 20:35 ` Micha Feigin
2004-05-31 19:38 ` Christoph Bussenius
0 siblings, 1 reply; 16+ messages in thread
From: Micha Feigin @ 2004-05-30 20:35 UTC (permalink / raw)
To: linux-c-programming
On Sun, May 30, 2004 at 09:12:32PM +0200, J. wrote:
> On Sun, 23 May 2004, ameer armaly wrote:
>
> > Hi all.
> > I was wondering if there are a set of functions/system calles to let me
> > know what someone's set their tty length and heighth too? I do this
> > because I don't want to presume 80x25 in case someone's got it set
> > otherwise.
> >
Its usually done using the environment variables in COLUMNS, AFAIK. They
appear after the first null of argv IIRC.
> > Ameer
>
> on the console the command `stty -a` will print:
> speed 9600 baud; rows 33; columns 89; line = 0;
> ....
> ....
> etc..
>
> For a c program have a look at the term manpage and use the settings from
> 'terminfo'
>
> #include <stdio.h>
> #include <term.h>
> #include <ncurses.h>
>
> int main(void) {
> int num_rows = 0, num_columns = 0;
>
> setupterm(NULL, fileno(stdout), (int *)0);
> num_rows = tigetnum("lines");
> num_columns = tigetnum("cols");
>
> printf("terminal:\ncolumns: %d\nrows %d\n", num_columns, num_rows);
>
> return 0;
> }
>
> etc.....
>
> G00dlUcK.....
>
> Jeroen Reynders.
>
> --
> http://www.xs4all.nl/~winnetou/
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> +++++++++++++++++++++++++++++++++++++++++++
> This Mail Was Scanned By Mail-seCure System
> at the Tel-Aviv University CC.
>
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: functions to determine dementions of console?
2004-05-30 20:35 ` Micha Feigin
@ 2004-05-31 19:38 ` Christoph Bussenius
2004-06-01 1:41 ` value computed is not used ?? J.
0 siblings, 1 reply; 16+ messages in thread
From: Christoph Bussenius @ 2004-05-31 19:38 UTC (permalink / raw)
To: linux-c-programming
On Sun, May 30, 2004 at 11:35:18PM +0300, Micha Feigin wrote:
> Its usually done using the environment variables in COLUMNS, AFAIK. They
> appear after the first null of argv IIRC.
I believe this is only a bash feature.
Regards,
Christoph
--
``There's no dark side of the moon, really
Matter of fact, it's all dark''
--Pink Floyd
^ permalink raw reply [flat|nested] 16+ messages in thread
* value computed is not used ??
2004-05-31 19:38 ` Christoph Bussenius
@ 2004-06-01 1:41 ` J.
2004-06-01 3:25 ` Glynn Clements
2004-06-01 7:30 ` Charlie Gordon
0 siblings, 2 replies; 16+ messages in thread
From: J. @ 2004-06-01 1:41 UTC (permalink / raw)
To: linux-c-programming
Tuesday, June 01 03:33:22
Hi ...
When I try to compile the listed program, with gcc version 2.95.4 20011002
and the command `gcc -Wall program.c -o program` It gives me a warning
message like: warning: value computed is not used
The program works perfectly fine, as far as I can judge the code isn't
wrong in any way ? And the value is certainly used.. Unfortunatly this
message shows to many times when I try to compile other code at my system.
Can anyone explain to me what the sense behind that warning is ? And what
to do about it ? e.g. what the ``better way`` of coding would be?
#include <stdio.h>
int main(void) {
char *ptr = NULL;
char str[] = "whats up";
for(ptr = str; *ptr; *ptr++) {
printf("%c", *ptr);
}
printf("\n");
return 0;
}
Thnkx a lot...
Jeroen.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: value computed is not used ??
2004-06-01 1:41 ` value computed is not used ?? J.
@ 2004-06-01 3:25 ` Glynn Clements
2004-06-01 7:30 ` Charlie Gordon
1 sibling, 0 replies; 16+ messages in thread
From: Glynn Clements @ 2004-06-01 3:25 UTC (permalink / raw)
To: linux-c-programming
J. wrote:
> When I try to compile the listed program, with gcc version 2.95.4 20011002
> and the command `gcc -Wall program.c -o program` It gives me a warning
> message like: warning: value computed is not used
>
> The program works perfectly fine, as far as I can judge the code isn't
> wrong in any way ? And the value is certainly used.. Unfortunatly this
> message shows to many times when I try to compile other code at my system.
>
> Can anyone explain to me what the sense behind that warning is ? And what
> to do about it ? e.g. what the ``better way`` of coding would be?
>
> #include <stdio.h>
>
> int main(void) {
> char *ptr = NULL;
> char str[] = "whats up";
>
> for(ptr = str; *ptr; *ptr++) {
for(ptr = str; *ptr; ptr++) {
There is no point in dereferencing "ptr++", which is why you get the
warning.
--
Glynn Clements <glynn.clements@virgin.net>
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: value computed is not used ??
2004-06-01 1:41 ` value computed is not used ?? J.
2004-06-01 3:25 ` Glynn Clements
@ 2004-06-01 7:30 ` Charlie Gordon
2004-06-01 16:08 ` Charlie Gordon
2004-06-01 21:58 ` Glynn Clements
1 sibling, 2 replies; 16+ messages in thread
From: Charlie Gordon @ 2004-06-01 7:30 UTC (permalink / raw)
To: linux-c-programming
Let's do code review :
> #include <stdio.h>
>
> int main(void) {
this is not a the correct propotype for main.
> char *ptr = NULL;
this initialization is useless.
> char str[] = "whats up";
what a horrible thing to write : this effectively defines an automatic
char array that gets initialized by copying the string "what's up".
while this is fine for global data, it is very inefficient for automatic
variables.
a better way would be:
const char *str = "whats up";
const char *ptr;
>
> for(ptr = str; *ptr; *ptr++) {
*ptr++ is causing the warning "value computed not used"
ptr++ suffices.
> printf("%c", *ptr);
for completeness, let it be known that some snoddy compilers will complain
that the result of printf is not used.
why not write:
putchar(*ptr);
> }
>
> printf("\n");
same as above:
putchar('\n');
> return 0;
> }
rework needed on 7 out of 8 non empty lines.
amazingly, there doesn't seem to be any algorithmic flaw in this simplistic
program.
Hope is helps.
Chqrlie.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: value computed is not used ??
2004-06-01 7:30 ` Charlie Gordon
@ 2004-06-01 16:08 ` Charlie Gordon
2004-06-01 21:58 ` Glynn Clements
1 sibling, 0 replies; 16+ messages in thread
From: Charlie Gordon @ 2004-06-01 16:08 UTC (permalink / raw)
To: linux-c-programming
> I gave the program as an example; After all the answers I received
> from y'all I think I'm gonna throw away some c books I have used in the
> past or even burn them in a ritual kind a way :-) They are loaded with c
> code like the above.
There is indeed so much crap in print !
Here is some palatable food for thought I would recommend :
- The C programming language, 2nd edition (Kernighan and Ritchie)
- The practice of Programming (Kernighan and Pike)
- C traps and Pitfalls (Andrew Koenig)
- The C puzzle book (Alan R. Feuer)
- Expert C Programming (Peter Van der Linden)
As a rule of thumb, stay away from books more than an inch thick or using
more than 4 colors on the cover.
> I understood everything in the above answer except for one issue ? Why is:
> int main(void) {
> The wrong prototype for main ? main() schould return `0' or `1' etc ?!?
> Thank you very much for taking the effort to explain and answer.
> Jeroen.
the proper prototype for main is
int main(int argc, char **argv);
or possibly :
int main(int argc, char *argv[]);
which is semantically equivalent, but emphasises the fact that argv points
to an array of char*
The mere fact that you do not use the arguments doesn't justify a change of
prototypes. It may even become a portability issue in some circumstances.
Glad to help.
Chqrlie.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: value computed is not used ??
2004-06-01 7:30 ` Charlie Gordon
2004-06-01 16:08 ` Charlie Gordon
@ 2004-06-01 21:58 ` Glynn Clements
2004-06-03 1:26 ` Micha Feigin
1 sibling, 1 reply; 16+ messages in thread
From: Glynn Clements @ 2004-06-01 21:58 UTC (permalink / raw)
To: linux-c-programming
Charlie Gordon wrote:
> > char *ptr = NULL;
> this initialization is useless.
Or possibly worse than useless.
Without the initialisation, if you tried to use it before it was
initialised, the compiler may generate a warning. The above
initialisation would eliminate the warning, and instead result in a
segfault (or, on an architecture which doesn't have an MMU, just
incorrect behaviour) at run time.
Responding to warnings by just "shutting the compiler up" is a common
programming flaw.
Probably the most common situation where this is dangerous is "fixing"
int/long mismatches using a type cast. You can get away with this if
sizeof(int) == sizeof(long) (e.g. i386). But on a system where
sizeof(int) != sizeof(long), the typecast may not work (or, at least,
not correctly), and eliminating the warnings will make it harder to
find (and actually fix) the problems.
--
Glynn Clements <glynn.clements@virgin.net>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: value computed is not used ??
2004-06-01 21:58 ` Glynn Clements
@ 2004-06-03 1:26 ` Micha Feigin
0 siblings, 0 replies; 16+ messages in thread
From: Micha Feigin @ 2004-06-03 1:26 UTC (permalink / raw)
To: linux-c-programming
On Tue, Jun 01, 2004 at 10:58:14PM +0100, Glynn Clements wrote:
>
> Charlie Gordon wrote:
>
> > > char *ptr = NULL;
> > this initialization is useless.
>
> Or possibly worse than useless.
>
> Without the initialisation, if you tried to use it before it was
> initialised, the compiler may generate a warning. The above
> initialisation would eliminate the warning, and instead result in a
On the other hand it allows you to check for pointer initialization
later to see if you already put a meaningful value in it, and in big
programs there is more use for that then the chance of a compiler error
by using an uninitialized value (especially since a debugger will catch
that in a second).
> segfault (or, on an architecture which doesn't have an MMU, just
> incorrect behaviour) at run time.
>
You have much worse head aches on MMU-less systems then accessing a NULL
initialized pointer, from experience ;-) (although it is a method the
kernel uses to generate and exception locking up the system on panic)
On the other hand what are the chances of him running into an mmu-less
system considering its only a few embedded systems that are not using an
MMU these days.
> Responding to warnings by just "shutting the compiler up" is a common
> programming flaw.
>
> Probably the most common situation where this is dangerous is "fixing"
> int/long mismatches using a type cast. You can get away with this if
> sizeof(int) == sizeof(long) (e.g. i386). But on a system where
> sizeof(int) != sizeof(long), the typecast may not work (or, at least,
> not correctly), and eliminating the warnings will make it harder to
> find (and actually fix) the problems.
>
> --
> Glynn Clements <glynn.clements@virgin.net>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> +++++++++++++++++++++++++++++++++++++++++++
> This Mail Was Scanned By Mail-seCure System
> at the Tel-Aviv University CC.
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: value computed is not used ??
@ 2004-06-01 17:34 Huber, George K RDECOM CERDEC STCD SRI
2004-06-01 19:09 ` Glynn Clements
0 siblings, 1 reply; 16+ messages in thread
From: Huber, George K RDECOM CERDEC STCD SRI @ 2004-06-01 17:34 UTC (permalink / raw)
To: linux-c-programming
-----Original Message-----
From: linux-c-programming-owner@vger.kernel.org
[mailto:linux-c-programming-owner@vger.kernel.org]On Behalf Of Charlie
Gordon
Sent: Tuesday, June 01, 2004 12:09 PM
To: linux-c-programming@vger.kernel.org
Subject: Re: value computed is not used ??
Charlie wrote (qoting J.)
>> I understood everything in the above answer except for one issue ? Why
is:
>> int main(void) {
>> The wrong prototype for main ? main() schould return `0' or `1' etc ?!?
>> Thank you very much for taking the effort to explain and answer.
>> Jeroen.
>the proper prototype for main is
>int main(int argc, char **argv);
>or possibly :
>int main(int argc, char *argv[]);
>which is semantically equivalent, but emphasises the fact that argv points
>to an array of char*
I to am a little confused on why you state that int main(void) is an
incorrect
prototype for main? Quoting from the C99 - draft standard,
"The function called at program startup is named main. The implementation
declares
no prototype for this function. It shall be defined with a return type of
int and with
no parameters:
int main(void) {/* ... */}
or with two parameters (referred to hear as argc and argv, though any names
may be used,
as they are local to the function in which they are declared):
int main(int argc, char* argv[]) {/* ... *.}
or equivalent, or in some other implementation-defined manner." (section
5.1.2.2.1)
This seems to imply that either prototype for main may be used. Is this a
new
addition to the C99 standard, or am I missing something here.
George
-
To unsubscribe from this list: send the line "unsubscribe
linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 16+ messages in thread* RE: value computed is not used ??
2004-06-01 17:34 Huber, George K RDECOM CERDEC STCD SRI
@ 2004-06-01 19:09 ` Glynn Clements
2004-06-01 20:58 ` Charlie Gordon
0 siblings, 1 reply; 16+ messages in thread
From: Glynn Clements @ 2004-06-01 19:09 UTC (permalink / raw)
To: Huber, George K RDECOM CERDEC STCD SRI; +Cc: linux-c-programming
Huber, George K RDECOM CERDEC STCD SRI wrote:
> > > I understood everything in the above answer except for one issue ? Why is:
> > > int main(void) {
> > > The wrong prototype for main ? main() schould return `0' or `1' etc ?!?
> > > Thank you very much for taking the effort to explain and answer.
> > > Jeroen.
>
> > the proper prototype for main is
> > int main(int argc, char **argv);
> > or possibly :
> > int main(int argc, char *argv[]);
> > which is semantically equivalent, but emphasises the fact that argv points
> > to an array of char*
>
> I to am a little confused on why you state that int main(void) is an
> incorrect
> prototype for main? Quoting from the C99 - draft standard,
>
> "The function called at program startup is named main. The implementation
> declares
> no prototype for this function. It shall be defined with a return type of
> int and with
> no parameters:
> int main(void) {/* ... */}
> or with two parameters (referred to hear as argc and argv, though any names
> may be used,
> as they are local to the function in which they are declared):
> int main(int argc, char* argv[]) {/* ... *.}
> or equivalent, or in some other implementation-defined manner." (section
> 5.1.2.2.1)
>
> This seems to imply that either prototype for main may be used. Is this a
> new addition to the C99 standard, or am I missing something here.
If a function uses the C calling convention (which is true for almost
everything except for functions which are exported from Windows DLLs),
you can safely supply more arguments than the function expects. So
long as the run-time supplies argc and argv, either prototype will
actually work.
In practice, Unix systems tend to use:
int main(int argc, char **argv, char **envp)
where envp is the array of environment variables (also available
through the global variable "environ").
So you can declare main() with any subset of these arguments, i.e. any
of:
int main(void)
int main(int argc)
int main(int argc, char **argv)
int main(int argc, char **argv, char **envp)
--
Glynn Clements <glynn.clements@virgin.net>
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: value computed is not used ??
2004-06-01 19:09 ` Glynn Clements
@ 2004-06-01 20:58 ` Charlie Gordon
2004-06-01 21:44 ` Glynn Clements
0 siblings, 1 reply; 16+ messages in thread
From: Charlie Gordon @ 2004-06-01 20:58 UTC (permalink / raw)
To: linux-c-programming
> > I to am a little confused on why you state that int main(void) is an
> > incorrect
> > prototype for main? Quoting from the C99 - draft standard,
> >
> > "The function called at program startup is named main. The
implementation
> > declares
> > no prototype for this function. It shall be defined with a return type
of
> > int and with
> > no parameters:
> > int main(void) {/* ... */}
> > or with two parameters (referred to hear as argc and argv, though any
names
> > may be used,
> > as they are local to the function in which they are declared):
> > int main(int argc, char* argv[]) {/* ... *.}
> > or equivalent, or in some other implementation-defined manner." (section
> > 5.1.2.2.1)
> >
>
> If a function uses the C calling convention (which is true for almost
> everything except for functions which are exported from Windows DLLs),
> you can safely supply more arguments than the function expects. So
> long as the run-time supplies argc and argv, either prototype will
> actually work.
>
> In practice, Unix systems tend to use:
>
> int main(int argc, char **argv, char **envp)
>
> where envp is the array of environment variables (also available
> through the global variable "environ").
>
> So you can declare main() with any subset of these arguments, i.e. any
> of:
>
> int main(void)
> int main(int argc)
> int main(int argc, char **argv)
> int main(int argc, char **argv, char **envp)
>
All right, you win.
It just strikes me as a bad habit to declare main without at least argc and
argv.
Proof reading is about idioms, the more you part from proven practices, the
easier it is to write bug ridden code, and the more tedious it becomes to
verify said code at code review level.
For example, for loops written with the <= operator are quite likely to
contain off by one errors. It catches my eye instantly, and I tend to be
rewarded often ! Same remark with casual do/while loops.
int main(void); strikes me as 'beginners C code' and trips me off.
So there is nothing wrong with the prototype, just like there was nothing
wrong with rest on the small program : it compiles, and performs correctly,
but you will all admit that my other remarks were still making valid points.
Chqrlie.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: value computed is not used ??
2004-06-01 20:58 ` Charlie Gordon
@ 2004-06-01 21:44 ` Glynn Clements
0 siblings, 0 replies; 16+ messages in thread
From: Glynn Clements @ 2004-06-01 21:44 UTC (permalink / raw)
To: Charlie Gordon; +Cc: linux-c-programming
Charlie Gordon wrote:
> All right, you win.
> It just strikes me as a bad habit to declare main without at least argc and
> argv.
> Proof reading is about idioms, the more you part from proven practices, the
> easier it is to write bug ridden code, and the more tedious it becomes to
> verify said code at code review level.
> For example, for loops written with the <= operator are quite likely to
> contain off by one errors. It catches my eye instantly, and I tend to be
> rewarded often ! Same remark with casual do/while loops.
> int main(void); strikes me as 'beginners C code' and trips me off.
>
> So there is nothing wrong with the prototype,
Ultimately, prototypes exist so that function calls can be
type-checked. As nothing[1] actually calls main(), the prototype is
irrelevant; a K&R-style definition[2] would suffice.
[1] Other than the runtime, which has already been compiled, and so
cannot make use of any prototype.
[2] I.e.:
int main()
int argc;
char **argv;
{ /* ... */ }
In a K&R-style definition, the argument declarations exist solely so
that the function body can refer to the arguments by name. If the
function doesn't actually use the arguments, there is no point in
declaring them.
> just like there was nothing wrong with rest on the small program :
> it compiles, and performs correctly,
That's a matter of opinion. As you pointed out, initialising an
automatic array is less than ideal; while it will work, it is seldom
the right approach.
But, more generally, the original program clearly wasn't intended to
be a practical utility, but an example. In which case (and coupled
with the fact that it was posted to this list), whether or not it
ultimately "works" is arguably less relevant than whether it was
written "correctly" (in an entirely subjective sense).
> but you will all admit that my other remarks were still making valid
> points.
Yes.
--
Glynn Clements <glynn.clements@virgin.net>
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2004-06-03 1:26 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-05-23 23:05 functions to determine dementions of console? ameer armaly
2004-05-24 2:09 ` Glynn Clements
2004-05-26 14:41 ` Christoph Bussenius
2004-05-30 19:12 ` J.
2004-05-30 20:35 ` Micha Feigin
2004-05-31 19:38 ` Christoph Bussenius
2004-06-01 1:41 ` value computed is not used ?? J.
2004-06-01 3:25 ` Glynn Clements
2004-06-01 7:30 ` Charlie Gordon
2004-06-01 16:08 ` Charlie Gordon
2004-06-01 21:58 ` Glynn Clements
2004-06-03 1:26 ` Micha Feigin
-- strict thread matches above, loose matches on Subject: below --
2004-06-01 17:34 Huber, George K RDECOM CERDEC STCD SRI
2004-06-01 19:09 ` Glynn Clements
2004-06-01 20:58 ` Charlie Gordon
2004-06-01 21:44 ` Glynn Clements
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).