Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #28771 > unrolled thread

What's new in C?

Back to article view | Back to comp.lang.c

Contents

  What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-11-28 19:41 -0700
    Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-11-28 19:15 -0800
      Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-06 02:43 -0700
        Re: What's new in C? James Kuyper <jameskuyper@verizon.net> - 2012-12-06 07:45 -0500
    Re: What's new in C? Noob <root@127.0.0.1> - 2012-11-29 10:36 +0100
      Re: What's new in C? Weland <weland@sdf.lonestar.org> - 2012-11-29 10:17 +0000
      Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-04 01:45 -0700
    Re: What's new in C? Weland <weland@sdf.lonestar.org> - 2012-11-29 09:48 +0000
      Re: What's new in C? David Brown <david@westcontrol.removethisbit.com> - 2012-11-29 13:50 +0100
    Re: What's new in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-11-29 05:55 -0800
      Re: What's new in C? Les Cargill <lcargill99@comcast.com> - 2012-11-29 12:48 -0600
        Re: What's new in C? Rui Maciel <rui.maciel@gmail.com> - 2012-11-30 10:46 +0000
          Re: What's new in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-11-30 05:31 -0800
            Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-11-30 14:22 +0000
            Re: What's new in C? Rui Maciel <rui.maciel@gmail.com> - 2012-11-30 15:04 +0000
              Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-30 16:41 +0000
                Re: What's new in C? James Kuyper <jameskuyper@verizon.net> - 2012-11-30 11:49 -0500
                Re: What's new in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-11-30 10:12 -0800
                Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-11-30 11:12 -0800
                  Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-30 22:26 +0000
                    Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-11-30 22:36 +0000
                      Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-30 23:27 +0000
                  Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-04 01:39 -0700
                    Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-12-04 00:43 -0800
                      Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-04 03:14 -0700
                        Re: What's new in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-04 12:50 +0000
                          Re: What's new in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-12-04 05:54 -0800
                          Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-04 20:51 +0000
                            Re: What's new in C? Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-04 16:09 -0500
                            Re: What's new in C? James Kuyper <jameskuyper@verizon.net> - 2012-12-04 16:19 -0500
                            Re: What's new in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-04 21:45 +0000
                              Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-05 01:13 +0000
                                Re: What's new in C? James Kuyper <jameskuyper@verizon.net> - 2012-12-04 20:36 -0500
                                  Re: What's new in C? Robert Wessel <robertwessel2@yahoo.com> - 2012-12-04 20:26 -0600
                                  Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-12-04 18:48 -0800
                                  Re: What's new in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-05 02:57 +0000
                                Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-12-05 01:42 +0000
                  Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-06 02:06 -0700
                    Re: What's new in C? James Kuyper <jameskuyper@verizon.net> - 2012-12-06 07:50 -0500
                      Re: What's new in C? JohnF <john@please.see.sig.for.email.com> - 2012-12-06 13:46 +0000
                        Re: What's new in C? James Kuyper <jameskuyper@verizon.net> - 2012-12-06 09:39 -0500
                Re: What's new in C? Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-30 15:52 -0500
                  Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-04 01:53 -0700
                    Re: What's new in C? Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-04 08:16 -0500
                      Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-04 21:18 +0000
                        Re: What's new in C? Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-04 18:04 -0500
                          Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-05 01:19 +0000
                            Re: What's new in C? Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-04 21:05 -0500
                              Re: What's new in C? Noob <root@127.0.0.1> - 2012-12-05 16:45 +0100
                          Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-06 01:45 -0700
                            Re: What's new in C? James Kuyper <jameskuyper@verizon.net> - 2012-12-06 08:12 -0500
                              Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-06 21:13 +0000
                            Re: What's new in C? Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-06 09:15 -0500
                              Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-12 18:28 -0700
          Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-11-30 11:22 -0800
            Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-04 03:04 -0700
    Re: What's new in C? Rui Maciel <rui.maciel@gmail.com> - 2012-11-29 18:19 +0000
      Re: What's new in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-11-29 11:41 -0800
    Re: What's new in C? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-11-30 20:50 +0000
      Re: What's new in C? Jens Gustedt <jens.gustedt@loria.fr> - 2012-11-30 23:35 +0100
        Re: What's new in C? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-12-05 03:26 +0000
          Re: What's new in C? gwowen <gwowen@gmail.com> - 2012-12-05 23:49 -0800
            Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-06 01:49 -0700
            Re: What's new in C? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-12-08 07:55 +0000
              Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-12-08 13:29 +0000
                Re: What's new in C? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-12-08 15:23 +0000
                  Re: What's new in C? Martin Shobe <martin.shobe@yahoo.com> - 2012-12-08 17:46 +0000
                  Re: What's new in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-12-08 10:45 -0800
                    Re: What's new in C? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-12-08 19:32 +0000
                  Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-12-08 18:55 +0000
                    Re: What's new in C? Ian Collins <ian-news@hotmail.com> - 2012-12-09 08:26 +1300
                      Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-12-08 20:12 +0000
                        Re: What's new in C? Ian Collins <ian-news@hotmail.com> - 2012-12-09 09:18 +1300
                          Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-12-08 21:21 +0000
                            Re: What's new in C? Ian Collins <ian-news@hotmail.com> - 2012-12-09 10:27 +1300
                            Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-12-08 13:36 -0800
                        Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-12-08 12:59 -0800
                          Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-12-08 22:10 +0000
                            Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-12-08 16:15 -0800
                            Re: What's new in C? Ian Collins <ian-news@hotmail.com> - 2012-12-09 14:23 +1300
                          Re: What's new in C? Ian Collins <ian-news@hotmail.com> - 2012-12-09 14:20 +1300
                    Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-12-08 11:32 -0800
                      Re: What's new in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-09 02:52 +0000
                      Re: What's new in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-09 02:53 +0000
                    Re: What's new in C? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-12-08 20:08 +0000
                      Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-12-08 20:25 +0000

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#28981

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

[toc] | [prev] | [next] | [standalone]

#28866

On 11/30/2012 11:41 AM, glen herrmannsfeldt wrote:
>
> Is it required that VLAs be stack allocated?

     No.  One plausible approach would be to malloc() space
for the array and insert a compiler-generated free() at block
exit.  This could be trickier than might appear at first glance,
though, since the block might exit via longjmp().

     Another possibility is to defer deallocation until some
convenient later time, like the next time a VLA is created.
VLA memory could be obtained from malloc() and appended to a
LIFO linked list of such areas, tagged with the "stack depth"
of the requestor.  At the next VLA allocation, the new requestor's
depth is determined and any areas allocated at deeper levels are
discarded.  (A semi-portable alloca() replacement by DA Gwyn
works this way.)  This could be combined with the first approach
to provide a safety net for the longjmp() case.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#28909

On 11/30/2012 01:52 PM, Eric Sosman wrote:
> On 11/30/2012 11:41 AM, glen herrmannsfeldt wrote:
>>
>> Is it required that VLAs be stack allocated?
>
>      No.  One plausible approach would be to malloc() space
> for the array and insert a compiler-generated free() at block
> exit.  This could be trickier than might appear at first glance,
> though, since the block might exit via longjmp().
>
>      Another possibility is to defer deallocation until some
> convenient later time, like the next time a VLA is created.
> VLA memory could be obtained from malloc() and appended to a
> LIFO linked list of such areas, tagged with the "stack depth"
> of the requestor.  At the next VLA allocation, the new requestor's
> depth is determined and any areas allocated at deeper levels are
> discarded.  (A semi-portable alloca() replacement by DA Gwyn
> works this way.)  This could be combined with the first approach
> to provide a safety net for the longjmp() case.
>

sounds like a library issue.
-- 
Cal

[toc] | [prev] | [next] | [standalone]

#28913

On 12/4/2012 3:53 AM, Cal Dershowitz wrote:
> On 11/30/2012 01:52 PM, Eric Sosman wrote:
>> On 11/30/2012 11:41 AM, glen herrmannsfeldt wrote:
>>>
>>> Is it required that VLAs be stack allocated?
>>
>>      No.  One plausible approach would be to malloc() space
>> for the array and insert a compiler-generated free() at block
>> exit.  This could be trickier than might appear at first glance,
>> though, since the block might exit via longjmp().
>>
>>      Another possibility is to defer deallocation until some
>> convenient later time, like the next time a VLA is created.
>> VLA memory could be obtained from malloc() and appended to a
>> LIFO linked list of such areas, tagged with the "stack depth"
>> of the requestor.  At the next VLA allocation, the new requestor's
>> depth is determined and any areas allocated at deeper levels are
>> discarded.  (A semi-portable alloca() replacement by DA Gwyn
>> works this way.)  This could be combined with the first approach
>> to provide a safety net for the longjmp() case.
>>
>
> sounds like a library issue.

     Not entirely: The library and compiler must cooperate.

     For the first approach described, the compiler needs to
generate the malloc() and free() calls, and needs to ensure
that the latter are executed no matter how the block exits.
Getting the free() to execute in the face of a longjmp() that
leaps back to a remote caller requires a certain intimacy
between compiler and library.

     The second approach relies on determining the call depth,
which the library cannot do without knowing  something about
how the compiler generates code.  DA Gwyn's alloca() simply
assumes that the compiler puts `auto' variables on a stack
that grows either up or down uniformly (that is, deeper frames
always use higher addresses or always use lower addresses).
This would not work at all with a compiler using a linked list
of stack frames scattered throughout memory.  The library cannot
do the whole job unaided; at the very least it needs assurances
from the compiler.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#28917

Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
> On 12/4/2012 3:53 AM, Cal Dershowitz wrote:

(snip on VLA allocation, either on, or not on, a stack.)

>> sounds like a library issue.
 
>     Not entirely: The library and compiler must cooperate.
 
>     For the first approach described, the compiler needs to
> generate the malloc() and free() calls, and needs to ensure
> that the latter are executed no matter how the block exits.
> Getting the free() to execute in the face of a longjmp() that
> leaps back to a remote caller requires a certain intimacy
> between compiler and library.

Seems to me that the intimacy is required for longjmp() in 
any case. 

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

Otherwise, in the case of completely static allocation
(common in Fortran 66 and Fortran 77) there is nothing
to deallocate.
 
>     The second approach relies on determining the call depth,
> which the library cannot do without knowing  something about
> how the compiler generates code.  DA Gwyn's alloca() simply
> assumes that the compiler puts `auto' variables on a stack
> that grows either up or down uniformly (that is, deeper frames
> always use higher addresses or always use lower addresses).
> This would not work at all with a compiler using a linked list
> of stack frames scattered throughout memory.  The library cannot
> do the whole job unaided; at the very least it needs assurances
> from the compiler.

Yes.

-- glen

[toc] | [prev] | [next] | [standalone]

#28920

On 12/4/2012 4:18 PM, glen herrmannsfeldt wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>> On 12/4/2012 3:53 AM, Cal Dershowitz wrote:
>
> (snip on VLA allocation, either on, or not on, a stack.)
>
>>> sounds like a library issue.
>
>>      Not entirely: The library and compiler must cooperate.
>
>>      For the first approach described, the compiler needs to
>> generate the malloc() and free() calls, and needs to ensure
>> that the latter are executed no matter how the block exits.
>> Getting the free() to execute in the face of a longjmp() that
>> leaps back to a remote caller requires a certain intimacy
>> between compiler and library.
>
> Seems to me that the intimacy is required for longjmp() in
> any case.

     On closer reading, it turns out that the intimacy isn't
*required* at all: If you longjmp() past a VLA's release, the
Standard allows the memory to leak.  So it's a QoI issue: A
VLA-unaware longjmp() is permitted to leak the memory (just
as it leaks other resources), or a VLA-aware longjmp() can
play nice and clean things up.

     Either way, the first approach cannot possibly be purely
a library matter: The compiler needs to arrange for the free()
(or equivalent) on any "normal" block exit, including exits by
way of return, break, continue, and goto.

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

> Otherwise, in the case of completely static allocation
> (common in Fortran 66 and Fortran 77) there is nothing
> to deallocate.

     Also nothing like a VLA.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#28927

Eric Sosman <esosman@comcast-dot-net.invalid> wrote:

(snip)

>     On closer reading, it turns out that the intimacy isn't
> *required* at all: If you longjmp() past a VLA's release, the
> Standard allows the memory to leak.  So it's a QoI issue: A
> VLA-unaware longjmp() is permitted to leak the memory (just
> as it leaks other resources), or a VLA-aware longjmp() can
> play nice and clean things up.

That is interesting.
 
>     Either way, the first approach cannot possibly be purely
> a library matter: The compiler needs to arrange for the free()
> (or equivalent) on any "normal" block exit, including exits by
> way of return, break, continue, and goto.
 
>> 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.

Is it, in general, possible to write a C library, including
longjmp(), that is independent of the compiler?

On many processors, there is more than one way to keep track
of stack pointers and frame pointers. There is even (still)
the question of caller or callee popping the arguments
off the stack. Then there are IBM mainframes with no stack.

-- glen

[toc] | [prev] | [next] | [standalone]

#28933

On 12/4/2012 8:19 PM, glen herrmannsfeldt wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>[... Glen snipped his own attribution ...]
>>> 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.
>
> Is it, in general, possible to write a C library, including
> longjmp(), that is independent of the compiler?

     I'd say "No."  The setjmp()/longjmp() pair are an obvious
case of interdependency: They can't know what to save and restore
unless they know about the code the compiler generates, and the
compiler itself must suppress some optimizations around a use
of setjmp().

     Other examples exist, but seem somewhat weaker.  The malloc()
suite is supposed to deliver memory that is properly aligned for
any C data type, but the required alignment depends on what kind
of code the compiler generates.  The <math.h> functions may rely
on the compiler to establish certain modes for rounding or NaN
handling, and/or the compiler may assume those modes are in force
for the in-line code it generates.  I have not studied C11's
thread support in any detail, but it seems probable that the
compiler and library cooperate to provide at least some of it.

     Don't overlook the Old Standbys: Compilers that recognize
sqrt() and memcpy() and assorted other library functions, and
generate in-line no-call code for them.[*]  Yes, the library still
needs to provide an actual, callable function (so you can aim a
function pointer at it), but `#define sqrt(x) _builtin_sqrt(x)'
is, I think, evidence of at least a compiler-library detente.
(These aren't mandatory, of course, so they don't contradict your
"possible" -- but they're evidence for the "desirable" question.)

     [*] 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."
That, I'd say, is a clear example of the compiler and library being
caught in flagrante delicto!  At compile-time, gcc's inspection of
printf() and scanf() formats vis-a-vis the other arguments is another
example of the compiler and library using knowledge of each other.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#28947

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

[toc] | [prev] | [next] | [standalone]

#28969

On 12/04/2012 04:04 PM, Eric Sosman wrote:
> On 12/4/2012 4:18 PM, glen herrmannsfeldt wrote:
>> Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>>> On 12/4/2012 3:53 AM, Cal Dershowitz wrote:
>>
>> (snip on VLA allocation, either on, or not on, a stack.)
>>
>>>> sounds like a library issue.
>>
>>>      Not entirely: The library and compiler must cooperate.
>>
>>>      For the first approach described, the compiler needs to
>>> generate the malloc() and free() calls, and needs to ensure
>>> that the latter are executed no matter how the block exits.
>>> Getting the free() to execute in the face of a longjmp() that
>>> leaps back to a remote caller requires a certain intimacy
>>> between compiler and library.
>>
>> Seems to me that the intimacy is required for longjmp() in
>> any case.
>
>      On closer reading, it turns out that the intimacy isn't
> *required* at all: If you longjmp() past a VLA's release, the
> Standard allows the memory to leak.  So it's a QoI issue: A
> VLA-unaware longjmp() is permitted to leak the memory (just
> as it leaks other resources), or a VLA-aware longjmp() can
> play nice and clean things up.

I find myself advocating "memory leaks" sometimes.  If C didn't leak its 
memory in some sense, there wouldn't be rudimentary interop.
>
>      Either way, the first approach cannot possibly be purely
> a library matter: The compiler needs to arrange for the free()
> (or equivalent) on any "normal" block exit, including exits by
> way of return, break, continue, and goto.
>
>> 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?
-- 
Cal

[toc] | [prev] | [next] | [standalone]

#28977

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

[toc] | [prev] | [next] | [standalone]

#28998

James Kuyper <jameskuyper@verizon.net> 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

[toc] | [prev] | [next] | [standalone]

#28979

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
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#29190

On 12/06/2012 07:15 AM, Eric Sosman wrote:
> 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.
>

Lifo is prettymuch it, isn't it?  It reminds me of what we in algebra 
call the "shoes and socks" principle.

-- 
Cal

[toc] | [prev] | [next] | [standalone]

#28862

Rui Maciel <rui.maciel@gmail.com> writes:
[...]
> IMO, you are missing the point.  Currently, the C programming language
> is the language as described in C11.  It doesn't really matter if that
> language is a superset of C89 or not, or if the features provided by
> either revision are already adequate.  The real important aspect is
> that it is supposed to be the standard baseline for all which is
> considered the C programming language, so that when someone says that
> program X is written in C, we know beforehand that we can use feature
> A, B, or C without wasting time finding out if any of those features
> are supported in platform M or N.  Once we are forced to waste time
> and resources dealing with specific variants of the same programming
> language, efficiency certainly won't go up, and things won't get any
> simpler or easier than they could be, and should be.

That's certainly the *purpose* of the C standard.  Unfortunately, it
hasn't been achieved.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

#28910

On 11/30/2012 12:22 PM, Keith Thompson wrote:
> Rui Maciel <rui.maciel@gmail.com> writes:
> [...]
>> IMO, you are missing the point.  Currently, the C programming language
>> is the language as described in C11.  It doesn't really matter if that
>> language is a superset of C89 or not, or if the features provided by
>> either revision are already adequate.  The real important aspect is
>> that it is supposed to be the standard baseline for all which is
>> considered the C programming language, so that when someone says that
>> program X is written in C, we know beforehand that we can use feature
>> A, B, or C without wasting time finding out if any of those features
>> are supported in platform M or N.  Once we are forced to waste time
>> and resources dealing with specific variants of the same programming
>> language, efficiency certainly won't go up, and things won't get any
>> simpler or easier than they could be, and should be.
>
> That's certainly the *purpose* of the C standard.  Unfortunately, it
> hasn't been achieved.
>

whatevs.  C is so much bigger than any one interest or endeavor.
--

[toc] | [prev] | [next] | [standalone]

#28808

Cal Dershowitz wrote:

> There seemed to be a significant numbers of individuals and companies
> who were just going to keep on working with C90, while others and I went
> toward C99.

C99 is perfectly fine, and although there weren't any revolutionary changes, 
and arguably it didn't introduced any change which was absolutely necessary, 
the ones it introduced were all, in general, useful and welcomed.

The one change which has been widely criticised was the infamous support 
for variable-length arrays (VLAs).  Personally, at first, I thought that 
VLAs represented a problem waiting to happen, but once we look into it we 
are forced to acknowledge that essentially the problems they pose aren't any 
different from the ones which were already caused by fixed-size arrays.  So, 
either VLAs aren't that bad, or we are forced to assume that the C 
programming language is broken by design since the K&R days, which wouldn't 
be a reasonable assumption. 

In spite of this, I'm one of those individuals who keeps on working with 
C90, and that has nothing to do with the programming language itself, and 
everything to do with Microsoft's unwillingness to support any other version 
of C beyond their weird implementation of C90 [1][2].  

As an example, I've started a small pet project (a small C library, FLOSS 
license) a few years ago.  It started off as a C99 project, but once it 
started do get off the ground, I started to receive requests to remove C99 
features and to make it a C90-compliant project.  Those users claimed they 
actually wanted to use the library as it was released but, as they were 
forced to use Microsoft's Visual Studio, as it didn't provided proper 
support for the C programming language, they weren't able to build the 
library without having to comb through the code themselves to remove the C99 
bits.

So, no matter how great C99 or C11 might be, those who are forced to stick 
with Microsoft Visual Studio will be barred from using any version of C 
beyond Microsoft's versions of C90.  The only alternative that Microsoft 
offers those poor souls is to migrate from C to Microsoft's version of 
C++98, and stick with the C subset.  Those users, which in some areas might 
be in significant numbers and/or in a position to impact and influence 
others, do restrict the adoption of C99 and C11.  To me, and according to my 
experience, that's the main reason (and quite possibly the only reason) why, 
after all these years, we still see discussions on what revision of the C 
programming language should be adopted  If it weren't for these shenanigans, 
the world would be a much simpler place.


Rui Maciel

[1] http://visualstudio.uservoice.com/forums/121579-visual-
studio/suggestions/2089423-c99-support
[2] http://www.infoq.com/news/2012/05/vs_c99_support/

[toc] | [prev] | [next] | [standalone]

#28819

On Thursday, November 29, 2012 6:19:42 PM UTC, Rui Maciel wrote:
> To me, and according to my experience, that's the main reason (and quite 
> possibly the only reason) why, after all these years, we still see 
> discussions on what revision of the C programming language should be adopted  
> If it weren't for these shenanigans, the world would be a much simpler place.
> 
Yes, I'm infuriated with Microsoft as well.

The problem is that what's good from a software engineering perspective isn't
so good in terms of Microsoft's strategy, which is constant churn.

[toc] | [prev] | [next] | [standalone]

#28865

On Thu, 2012-11-29, Cal Dershowitz wrote:
> It's been forever since I posted as OP in c.l.c.  When I was learning C 
> from Dan Pop, the authors of unleashed, Chris Torek, Keith and even 
> Chuck before he was wrong all the time, there was always the tension 
> between dos and linux platforms, Topic Zealotry: there is no topic but 
> the topic, but also there was good, topical and honest disagreements 
> about C itself.
>
> There seemed to be a significant numbers of individuals and companies 
> who were just going to keep on working with C90, while others and I went 
> toward C99.
>
> I'm wondering how it all turned out.  While the C specification is 
> concise and small, the C family of users and applications is 
> monstrously-large.
>
> Did embedded systems eventually embrace newer C?

For the one I'm working on: we're talking about going C99, but it
never happens.  And the Linux kernel seems stuck with C90 for some
reason.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#28868

Am 30.11.2012 21:50, schrieb Jorgen Grahn:

> For the one I'm working on: we're talking about going C99, but it
> never happens.  And the Linux kernel seems stuck with C90 for some
> reason.

No, that is much too imprecise to be true. The linux kernel uses its
own C dialect which is a pragmatic mixture of C89, C99 and gcc
specific features. They have some C99 that they disallow in the
kernel, some for good reasons, e.g I can easily be convinced that VLA
are not such a good idea in an OS kernel. Whether or not to allow
mixed declarations and statement (which Linus definitively doesn't
want) is more a matter of taste and/or coding style.

Jens

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web