functions to determine dementions of console?

functions to determine dementions of console?

[ameer armaly]

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

Re: functions to determine dementions of console?

[Glynn Clements]

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

Re: functions to determine dementions of console?

[Christoph Bussenius]

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

Re: functions to determine dementions of console?

[J.]

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/

Re: functions to determine dementions of console?

[Micha Feigin]

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.
> 

Re: functions to determine dementions of console?

[Christoph Bussenius]

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

value computed is not used ??

[J.]

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.

Re: value computed is not used ??

[Glynn Clements]

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>

Re: value computed is not used ??

[Charlie Gordon]

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.

Re: value computed is not used ??

[Charlie Gordon]

> 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.

Re: value computed is not used ??

[Glynn Clements]

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>

Re: value computed is not used ??

[Micha Feigin]

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.
>