Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: What's new in C?

Reply
Thread Tools

Re: What's new in C?

 
 
Keith Thompson
Guest
Posts: n/a
 
      12-05-2012
James Kuyper <(E-Mail Removed)> writes:
[...
> Objects defined inside of a block have a lifetime that starts at the
> point of definition, and ends upon exiting the block. If the block is
> entered and exited multiple times, for example a block associated with a
> while() statement, objects defined inside the block have a separate
> lifetime during each pass through the block. Does that correspond to
> your concept of an allocation level?
> I believe that this has been true for at least as long as C has had a
> standard, and probably as far back as K&R C, but I can only be sure
> about C99 and later.


Actually, the lifetime of a non-VLA object defined inside a block
extends from entry into the block until execution of the block
ends in any way. So an object can exist for some time before its
declaration is reached. (You can write some ugly code using gotos
for which the distinction matters.)

VLAs exist only from the declaration of the object (since the size
isn't necessarily known before that).

And of course this is all subject to the as-if rule. It's not
uncommon, I think, for everything to be allocated on function entry,
even if some objects in the function have a narrower lifetime.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      12-05-2012
James Kuyper <(E-Mail Removed)> writes:

> On 12/04/2012 08:13 PM, glen herrmannsfeldt wrote:
> ...
>> PL/I has DO, which groups statements but isn't a scoping level,
>> and BEGIN which is. I had thought { } was more like DO.
>>
>> Without VLAs, it isn't so obvious when variables are allocated
>> in C, but I had thought, (though maybe that was C90) the { }
>> wasn't a an allocation level, even if you declared variables
>> inside.

>
> C doesn't have anything that's referred to as an "allocation level", but
> it seems to me that the concept you're referring to may be related to
> what the C standard describes in terms of object lifetimes.
> In C, blocks delimit scope and also limit the lifetime of objects
> defined within them.
>
> Objects defined inside of a block have a lifetime that starts at the
> point of definition,


Not for ordinary objects. For objects that aren't VLA, the lifetime
starts at entry into the block, though the initialisation occurs only
when the declaration is reached. Obviously this can't be true for VLAs,
so the rule for them is as I gave in a previous post.

> and ends upon exiting the block. If the block is
> entered and exited multiple times, for example a block associated with a
> while() statement, objects defined inside the block have a separate
> lifetime during each pass through the block. Does that correspond to
> your concept of an allocation level?
> I believe that this has been true for at least as long as C has had a
> standard, and probably as far back as K&R C, but I can only be sure
> about C99 and later.


It was true way back in pre-ANSI, K&R, C. But it was once not true. In
the Silurian, when return statements needed brackets round the
expression, and compound assignments were written backwards (=+ and so
on), declarations were not permitted at the start of a block, but only
at the head of a function. Still, despite being so long ago, I think it
lives on in a sort of folk memory...

--
Ben.
 
Reply With Quote
 
 
 
 
Noob
Guest
Posts: n/a
 
      12-05-2012
Eric Sosman wrote:

> A former colleague who'd been a compiler jockey told me of
> tweaking his employer's compiler to recognize `printf("%s\n", p)'
> and replace it with `puts(p)'. Why? "It helped the SPECmark."


As a matter of fact, someone thought GCC should do this

$ cat optim.c
#include <stdio.h>
void foo(void) { printf("FOO\n"); }
void bar(void) { printf("%s\n", "BAR"); }

$ gcc -O1 -S optim.c

.file "optim.c"
.section .rdata,"dr"
LC0:
.ascii "FOO\0"
.text
..globl _foo
.def _foo; .scl 2; .type 32; .endef
_foo:
pushl %ebp
movl %esp, %ebp
subl $24, %esp
movl $LC0, (%esp)
call _puts
leave
ret
.section .rdata,"dr"
LC1:
.ascii "BAR\0"
.text
..globl _bar
.def _bar; .scl 2; .type 32; .endef
_bar:
pushl %ebp
movl %esp, %ebp
subl $24, %esp
movl $LC1, (%esp)
call _puts
leave
ret
.def _puts; .scl 2; .type 32; .endef

 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      12-06-2012
On 12/06/2012 04:06 AM, Cal Dershowitz wrote:
....
> Keith, the contemporary fortran standard defined interop w.r.t. C99. Is
> there anything new or deleted with stuff like this in 2011?
>
> As C rightly figures itself as the lingua franca, I'll anticipate that
> the answer is no.


You're correct.

> Is there a clause that says, "what held in 99 holds now without further
> comment."


No, the differences between C99 and C2011 include both a small number of
things that have been removed or rendered optional, and a larger number
of new things.
--
James Kuyper
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      12-06-2012
On 12/06/2012 03:45 AM, Cal Dershowitz wrote:
> On 12/04/2012 04:04 PM, Eric Sosman wrote:
>> On 12/4/2012 4:18 PM, glen herrmannsfeldt wrote:

....
>>> Well, I suppose in some processors the stack operation might
>>> be predefined well enough that there weren't any possible
>>> variations.

>>
>> Sorry; I don't understand this.

>
> Does standard C still have no notion of a stack?


The C standard still doesn't use the word stack. As always, the rules
governing the lifetime of objects with automatic storage duration have
LIFO semantics that make it natural to implement them using a stack, but
an actual hardware stack is still not required. Even a software stack is
not strictly necessary, though it's hard to come up with a plausible
justification for not using one.
--
James Kuyper
 
Reply With Quote
 
JohnF
Guest
Posts: n/a
 
      12-06-2012
James Kuyper <(E-Mail Removed)> wrote:
> Cal Dershowitz wrote:
>> ...
>> Is there a clause that says, "what held in 99 holds now without further
>> comment."

>
> No, the differences between C99 and C2011 include both a small number of
> things that have been removed or rendered optional, and a larger number
> of new things.


Doesn't "removed" introduce (unnecessary?) backward compatibility
problems? I noticed Keith mentioned gets() is removed; moreover, he
added "it's not even optional". Seems like "unnecessary roughness":
sounds like a compiler that chooses to implement gets() is deemed
non-compliant, despite doing everything else right.
--
John Forkosh ( mailto: (E-Mail Removed) where j=john and f=forkosh )
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      12-06-2012
On 12/6/2012 3:45 AM, Cal Dershowitz wrote:
> On 12/04/2012 04:04 PM, Eric Sosman wrote:
>> On 12/4/2012 4:18 PM, glen herrmannsfeldt wrote:
>>> [...]
>>> Well, I suppose in some processors the stack operation might
>>> be predefined well enough that there weren't any possible
>>> variations.

>>
>> Sorry; I don't understand this.

>
> Does standard C still have no notion of a stack?


C requires LIFO ordering of function entries and exits, and
a LIFO ordering of the lifetimes of function parameters, `auto'
variables, and `register' variables. The Standard says nothing
about how the implementation provides this. We can infer the
existence of at least one abstract stack, but we cannot say with
certainty that there is only one, nor that each stack occupies
a contiguous stretch of memory, nor anything much, really. We
know there's a LIFO property, and that's about all.

--
Eric Sosman
(E-Mail Removed)d
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      12-06-2012
On 12/06/2012 08:46 AM, JohnF wrote:
....
> Doesn't "removed" introduce (unnecessary?) backward compatibility
> problems? I noticed Keith mentioned gets() is removed; moreover, he
> added "it's not even optional". Seems like "unnecessary roughness":
> sounds like a compiler that chooses to implement gets() is deemed
> non-compliant, despite doing everything else right.


I wouldn't agree with your "unnecessary" judgment - so far the only
features of C that have been removed (implicit int, gets()) were things
that should ideally have never been there. Breaking code that depends
upon those features is a good thing, because all such code should have
been rewritten a decade or two ago. Also, I don't approve of optional
features.

However, for backwards compatibility these features should ideally have
been deprecated in at least one version of the standard before being
removed in the next version - but the committee decided otherwise. I
don't see that as a big problem. If we want to dream about re-writing
C's history, I'd vote for deprecating them in C89.

In practice, it's not as hard on an implementation as it sounds. Support
for gets() could be turned on by an option that renders the compiler
non-conforming; it could even be on by default, and turned off by an
option, though I would not recommend that. Most compilers are
non-conforming in their default mode. Also, a fully conforming
implementation could support a #pragma which turns on support for
gets(). I would guess that most C2011 compilers will choose one or both
of those two options.
--
James Kuyper
 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      12-06-2012
James Kuyper <(E-Mail Removed)> wrote:
> On 12/06/2012 03:45 AM, Cal Dershowitz wrote:


(snip)
>> Does standard C still have no notion of a stack?


> The C standard still doesn't use the word stack. As always, the rules
> governing the lifetime of objects with automatic storage duration have
> LIFO semantics that make it natural to implement them using a stack, but
> an actual hardware stack is still not required. Even a software stack is
> not strictly necessary, though it's hard to come up with a plausible
> justification for not using one.


IBM S/360 and S/370 don't have any stack instructions.

ESA/390 has the linkage stack, but as far as I know it isn't
normally used for subroutine calls.

For OS/360 and descendants, a doubly linked list is used to
save return addresses and registers. Fortran 66 and 77
(no recursion allowed) usually use statically allocated
save areas. (That is what OS/360 calls them.)
Languages that allow recursion dynamically allocate their
save areas, usually along with allocation for automatic data.

The way OS/360 (and descendants) call your program is pretty
much the same way as described above. It is also the way
that many internal calls inside the OS are done.

Progams will often allocate larger blocks and parcel them
out as needed, a little more efficient than using GETMAIN
for each one.

With large address spaces and virtual stacks, maybe there
is no waste in memory for a stack, even when the recursion
depth is unknown. Still, it does seem nice to have one
call convention for everyone. With stacks, someone has to
create the stack in the first place, and for security
reasons, among others, that is usually not the same stack
as used inside the OS.

-- glen
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Javascript new-new-new-new-newbee weblinkunlimited@gmail.com Javascript 2 03-11-2008 01:15 AM
New computer, New OS, New Wireless Problem :-\ =?Utf-8?B?RGFu?= Wireless Networking 3 07-31-2005 02:11 PM
[Firefox] Use New Tab instead of New Window? paul j Firefox 7 04-07-2005 09:40 PM
Why can not register a new .net passport or a new hotmail account Alick Lv MCSD 1 01-04-2004 06:12 PM



Advertisments