Friday, April 16, 2010

comp.lang.c - 10 new messages in 5 topics - digest

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* In the Matter of Herb Schildt: a Detailed Analysis of "C: The Complete
Nonsense" - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/caf17fab4e7d8530?hl=en
* cannot perform desired operation - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/2d8c17a39ab43783?hl=en
* adding two hex numbers - 5 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/29688d45a35bc095?hl=en
* C - gets() function implementation help - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/7bd0bc765a2e9603?hl=en
* memset pointer to 0 - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/0844332d363fdb33?hl=en

==============================================================================
TOPIC: In the Matter of Herb Schildt: a Detailed Analysis of "C: The Complete
Nonsense"
http://groups.google.com/group/comp.lang.c/t/caf17fab4e7d8530?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Apr 15 2010 10:04 pm
From: David Thompson


On 5 Apr 2010 16:27:33 GMT, blmblm@myrealbox.com
<blmblm@myrealbox.com> wrote:

> In article <f68bd6a2-795b-4d8b-92b1-dbfb8a3a031d@r18g2000yqd.googlegroups.com>,
> spinoza1111 <spinoza1111@yahoo.com> wrote:
<rest snipped>
> It may be that all(?) of the ways of invoking a program in a
> Windows environment ignore its return value. This is not the
> case in all operating systems:
>
The Win32-standard command processor CMD.EXE can check (easily
although a tad uglily), and I'm pretty sure the earlier and generally
less powerful MSDOS COMMAND.COM also. The two other ways I commonly
use, mingw (port of) gawk and ActiveState (port of) perl, also do,
although perl uses the (annoying) Unix form of shifting left 8 bits.

It is not as standard/conventional among Windows *programs* to provide
meaningful exit values as it is among Unix ones, so it is not as often
*useful* to check, but it is possible.

However, doubleclicking (or select+Open/etc) on a desktop icon or
file-explorer entry, for the program or a file associated with it, or
Start / Run (or CMD START), do discard the exit value. And the first
of these is the only way used by many naive users, and the two of them
together IME used often even by power users, so this is an important
even if technically exceptional case.

> Command shells for UNIX-like systems may (usually do?) provide
> access to the return value via an environment variable, and some
> shell scripts make use of it. Other mechanisms for invoking
> programs (e.g., fork/exec*/waitpid) also provide access to the
> return code.
>
A shell variable, but not an environment variable; though often
conflated those aren't quite the same thing. And Unix shells can also
use the exit value implicitly: 'if foo; then bar; fi' runs foo, and if
it exits successfully (defined as 0) then the shell runs bar,
otherwise it doesn't. Similarly for while, &&, ||. In addition to many
(not all, as above) Unix-designed programs returning a usable status
as a side-effect of their 'primary' operation, there have long been
some programs, most notably 'test', whose *only* purpose is to return
a status value; newer shells like bash often have this functionality
builtin but systems often still have the external program also.

> And didn't JCL for the venerable IBM OS/VS operating system(s) use
> the value returned by a called program to control execution flow?
> That's how I remember it anyway.
>
All versions/descendants of OS/360, yes. But very limited 'control',
basically just continue or stop/abort.

And of course there's VMS, frequently cited here because it had a
whole complex scheme of status values in which zero meant (a) failure,
so C exit(0) or exit(EXIT_SUCCESS) had to actually map to something
nonzero -- perhaps 1, the simplest (but very not only) success.


==============================================================================
TOPIC: cannot perform desired operation
http://groups.google.com/group/comp.lang.c/t/2d8c17a39ab43783?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Apr 15 2010 10:06 pm
From: jiten


Hi all,
I have a small request. I am a newbie to lex/yacc and as part of term
assignment was developing a calculator. But, I have problem that I
cannot perform any real data type operation. Not even addition. At
best, the response is :
> command not found (e.g., for i/p: 5.0+6.0); else it is 'syntax
error'.
Kindly find the two files posted below:

calc.y
==========
%{#include<stdio.h>
%}
/*%union {double real; int integer;}*/
%token <real> REAL
%token <integer> INTEGER
%token PLUS MINUS TIMES DIVIDE LP RP NL UL
%type <real> rexpr
%type <integer> iexpr
%left PLUS MINUS
%left TIMES DIVIDE
%left UMINUS
%%
lines : /* nothing*/
| lines line
;
line : NL
|iexpr NL
{ printf("%d)%d\n", lineno, $1);}
|rexpr UL
{ printf("%d)%15.8lf\n", lineno, $1);}
iexpr : INTEGER
|iexpr PLUS iexpr
{ $$ = $1 + $3; }
|iexpr MINUS iexpr
{ $$ = $1 - $3; }
|iexpr TIMES iexpr
{ $$ = $1 * $3; }
|iexpr DIVIDE iexpr
{ if($3) $$ = $1/$3;
else {yyerror("divide by zero"); }
}
|MINUS iexpr %prec UMINUS
{ $$ = -$2;}
|LP iexpr RP
{ $$ = $2; }
rexpr : REAL
|rexpr PLUS rexpr
{ $$ = $1 + $3; }
|rexpr MINUS rexpr
{ $$ = $1 - $3; }
|rexpr TIMES rexpr
{ $$ = $1 * $3; }
|rexpr DIVIDE rexpr
{ if($3) $$ = $1/$3;
else {yyerror("divide by zero"); }
}
|MINUS rexpr %prec UMINUS
{ $$ = -$2;}
|LP rexpr RP
{ $$ = $2; }
|iexpr PLUS rexpr
{ $$ = (double)$1 + $3; }
|iexpr MINUS rexpr
{ $$ = (double)$1 - $3; }
|iexpr TIMES rexpr
{ $$ = (double)$1 * $3; }
|iexpr DIVIDE rexpr
{ if($3) $$ = (double)$1/$3;
else {yyerror("divide by zero"); }
}
|rexpr PLUS iexpr
{ $$ = $1 +(double)$3;}
|rexpr MINUS iexpr
{ $$ = $1 -(double)$3;}
|rexpr DIVIDE iexpr
{ if($3) $$ = (double)$1/$3;
else{yyerror("divide by zero"); }
}
%%
#include "lex.yy.c"
int lineno;
main()
{
return yyparse();
}
yyerror(char *s)
{
fprintf(stderr, "%s\n", s);
}

=============
calc.l
-----------
%{
#include"y.tab.h"
%}

integer [0-9]+
dreal ([0-9]*\.[0-9]+)
ereal ([0-9]*\.[0-9]+[Ee][+-]?[0-9]+)
real {dreal}|{ereal}
nl \n

%%

[ \t] ;
{integer} { sscanf(yytext, "%d", &yylval.integer);
return INTEGER;
}
{real} { sscanf(yytext, "%lf", &yylval.real);
return REAL;
}
\+ {return PLUS;}
\- {return MINUS;}
\* {return TIMES;}
\/ {return DIVIDE;}
\( {return LP;}
\) {return RP;}
{nl} {extern int lineno; lineno++; return NL;}
. {return yytext[0];} /* to return any character otherwise
not handled as a single char. token to the parser*/

%%

int yywrap() { return 1;}


Best regards,
Jitender Ahuja


== 2 of 2 ==
Date: Thurs, Apr 15 2010 10:14 pm
From: Seebs


On 2010-04-16 00:06:52 -0500, jiten said:

> Hi all,
> I have a small request. I am a newbie to lex/yacc and as part of term
> assignment was developing a calculator.

lex and yacc are not C, even though they are often used to develop C code.

I'd guess that comp.unix.programmer would have more people who are up to speed
on them.

If you're getting messages like "command not found", that sounds like you're
ending up entering your commands at the shell prompt, rather than submitting
them to your program -- but this would be something that, again, has more to
do with your work environment than with C.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!


==============================================================================
TOPIC: adding two hex numbers
http://groups.google.com/group/comp.lang.c/t/29688d45a35bc095?hl=en
==============================================================================

== 1 of 5 ==
Date: Thurs, Apr 15 2010 10:19 pm
From: Ram


Hi,

sorry for asking silly Question

i have two hex values

unsigned int *x = 0x37a00000
unsigned int *y;

*y = *x + 0x300000;

printf("*final val = 0x%x\n",*y);

it should print o/p as 0x37d00000

but its printing output as 0x300000

am i doing blunder??

Thanks in advance
-Ram


== 2 of 5 ==
Date: Thurs, Apr 15 2010 10:25 pm
From: Alexander Bartolich


Ram wrote:
> [...]
> i have two hex values
>
> unsigned int *x = 0x37a00000
^
Here you declare a pointer to unsigned int and initialize it with
the address 0x37a00000.

> unsigned int *y;

Another pointer. It is not initialized.

> *y = *x + 0x300000;

On the left side of the assignment you dereference an unitialized
pointer. This is likely to crash.

On the right side you read the unsigned int at address 0x37a00000.
This will yield some random value.

> printf("*final val = 0x%x\n",*y);
>
> it should print o/p as 0x37d00000
>
> but its printing output as 0x300000

Well, you are lucky. Writing to the random address did not crash.
And the unsigned int at address 0x37a00000 has the value 0.

> am i doing blunder??

Indeed.

--


== 3 of 5 ==
Date: Thurs, Apr 15 2010 10:33 pm
From: Sjouke Burry


Ram wrote:
> Hi,
>
> sorry for asking silly Question
>
> i have two hex values
>
> unsigned int *x = 0x37a00000
> unsigned int *y;
>
> *y = *x + 0x300000;
>
> printf("*final val = 0x%x\n",*y);
>
> it should print o/p as 0x37d00000
>
> but its printing output as 0x300000
>
> am i doing blunder??
>
> Thanks in advance
> -Ram
You are doing pointer calculations, and an int pointer
plus an int might really calculate (ptr + sizof(int)*n)
or it might crash your computer.

Also to print a pointer you might use %p instead of 0x%x.


== 4 of 5 ==
Date: Thurs, Apr 15 2010 10:56 pm
From: Seebs


On 2010-04-16 00:19:21 -0500, Ram said:

> Hi,
>
> sorry for asking silly Question
>
> i have two hex values
>
> unsigned int *x = 0x37a00000

You are declaring a *pointer* named x, and setting it to an
arbitrary value.

> unsigned int *y;

Here you have a pointer that doesn't point anywhere.

> *y = *x + 0x300000;

Here, you take the contents of your arbitrary-value pointer, and
add something to it, and store the result in something you've never
heard of.

> printf("*final val = 0x%x\n",*y);
>
> it should print o/p as 0x37d00000

Please don't use abbreviations like "o/p". They are easy for people to
misunderstand and don't save much time to begin with.

> but its printing output as 0x300000
>
> am i doing blunder??

Yes.

Try:

unsigned int x = 0x37d000000;
unsigned int y;

y = x + 0x3000000;

printf("final val = 0x%x\n", y);

You don't need the '*' because you don't actually intend to use pointers here.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 5 of 5 ==
Date: Thurs, Apr 15 2010 11:17 pm
From: Michal Nazarewicz


Ram <rammohan2b@gmail.com> writes:

> i have two hex values
>
> unsigned int *x = 0x37a00000
> unsigned int *y;
>
> *y = *x + 0x300000;
>
> printf("*final val = 0x%x\n",*y);
>
> it should print o/p as 0x37d00000
>
> but its printing output as 0x300000

On a side note of what was already said, you may consider using
intrptr_t if you really need to do such low-level arithmetic on
pointers and later cast it to a pointer.

--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86-tlen.pl>--<jid:mina86-jabber.org>--ooO--(_)--Ooo--

==============================================================================
TOPIC: C - gets() function implementation help
http://groups.google.com/group/comp.lang.c/t/7bd0bc765a2e9603?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Apr 15 2010 11:09 pm
From: Michal Nazarewicz


>> Seebs <usenet-nospam@seebs.net> writes:
>>> Your instructor may not know this, but strictly speaking, you're not
>>> allowed to make a function named gets() -- that name is reserved.

> On 2010-04-15, Michal Nazarewicz <mina86@tlen.pl> wrote:
>> Not unless it has internal linkage though?

Seebs <usenet-nospam@seebs.net> writes:
> External, I assume you mean?

Yes, of course.

--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86-tlen.pl>--<jid:mina86-jabber.org>--ooO--(_)--Ooo--

==============================================================================
TOPIC: memset pointer to 0
http://groups.google.com/group/comp.lang.c/t/0844332d363fdb33?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Apr 15 2010 11:39 pm
From: Nick <3-nospam@temporary-address.org.uk>


"christian.bau" <christian.bau@cbau.wanadoo.co.uk> writes:

> On Apr 15, 10:01 pm, Nick <3-nos...@temporary-address.org.uk> wrote:
>
>> Can you have a system where before storing or retrieving any pointer
>> value it is XORed with the address of the variable it's stored in?  In
>> that case, all normal pointer operations would work (including comparing
>> two pointers to the same place) but if you read the bits directly they
>> would be different.
>
> Mostly no. The bits stored would be the "representation" of the
> pointer, and certain classes of pointer types are guaranteed to have
> compatible representations. So if you memcpy from the address of one
> char* to the address of another char*, both char* will point to the
> same char. It would be possible that in an implementation with 32 bit
> address space a pointer is 64 bit, and the lower 32 bit contain the
> address of the object pointed to, and the higher 32 bit contain the
> address where the pointer is stored if you store it using an
> assignment. Still, memcpy'ing a pointer would have to produce a valid
> pointer again.

So if we have:
sometype x;
sometype *a, *b;
a = &x;
b = &x;

then
memcmp(a,b,sizeof(x))
has to return zero?

You say "certain types". I assuming this is true when sometype is char,
which others is it true for?
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk


==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

<< Home


Real Estate