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

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

Non-(sub)-standard C

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

Contents

  Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-20 08:56 -0700
    Re: Non-(sub)-standard C Noob <root@127.0.0.1> - 2015-05-20 18:02 +0200
    Re: Non-(sub)-standard C rick.c.hodgin@gmail.com - 2015-05-20 09:20 -0700
    Re: Non-(sub)-standard C Les Cargill <lcargill99@comcast.com> - 2015-05-20 12:12 -0500
    Re: Non-(sub)-standard C Keith Thompson <kst-u@mib.org> - 2015-05-20 10:53 -0700
      Re: Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-21 09:44 -0700
        Re: Non-(sub)-standard C rick.c.hodgin@gmail.com - 2015-05-21 10:22 -0700
        Re: Non-(sub)-standard C Keith Thompson <kst-u@mib.org> - 2015-05-21 10:46 -0700
        Re: Non-(sub)-standard C Andrew Smallshaw <andrews@sdf.lonestar.org> - 2015-05-21 19:39 +0000
          Re: Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-22 10:13 -0700
            Re: Non-(sub)-standard C Keith Thompson <kst-u@mib.org> - 2015-05-22 14:02 -0700
              Re: Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-23 09:41 -0700
                Re: Non-(sub)-standard C Robert Wessel <robertwessel2@yahoo.com> - 2015-05-23 13:37 -0500
                Re: Non-(sub)-standard C Keith Thompson <kst-u@mib.org> - 2015-05-23 14:38 -0700
                  Re: Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-24 10:10 -0700
                    Re: Non-(sub)-standard C wpihughes@gmail.com - 2015-05-24 12:53 -0700
                    Re: Non-(sub)-standard C rick.c.hodgin@gmail.com - 2015-05-24 13:05 -0700
                      Re: Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-25 09:01 -0700
                        Re: Non-(sub)-standard C rick.c.hodgin@gmail.com - 2015-05-25 10:19 -0700
                          Re: Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-26 11:01 -0700
                            Re: Non-(sub)-standard C rick.c.hodgin@gmail.com - 2015-05-26 11:40 -0700
                              Re: Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-27 10:28 -0700
                                Re: Non-(sub)-standard C rick.c.hodgin@gmail.com - 2015-05-27 11:13 -0700
                                  Re: Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-28 12:20 -0700
                                    Re: Non-(sub)-standard C rick.c.hodgin@gmail.com - 2015-05-28 12:26 -0700
                                      Re: Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-29 10:12 -0700
                                        Re: Non-(sub)-standard C wpihughes@gmail.com - 2015-05-29 13:57 -0700
                        Re: Non-(sub)-standard C rick.c.hodgin@gmail.com - 2015-05-26 11:33 -0700
                    Re: Non-(sub)-standard C Keith Thompson <kst-u@mib.org> - 2015-05-24 14:03 -0700
                      Re: Non-(sub)-standard C Richard Heathfield <rjh@cpax.org.uk> - 2015-05-24 22:09 +0100
                        Re: Non-(sub)-standard C Ian Collins <ian-news@hotmail.com> - 2015-05-25 16:46 +1200
                          Re: Non-(sub)-standard C James Kuyper <jameskuyper@verizon.net> - 2015-05-25 00:55 -0400
                            Re: Non-(sub)-standard C Ian Collins <ian-news@hotmail.com> - 2015-05-25 18:08 +1200
                              Re: Non-(sub)-standard C Richard Heathfield <rjh@cpax.org.uk> - 2015-05-25 10:58 +0100
                                Re: Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-25 09:12 -0700
                              Re: Non-(sub)-standard C James Kuyper <jameskuyper@verizon.net> - 2015-05-25 18:40 -0400
                                Re: Non-(sub)-standard C Ian Collins <ian-news@hotmail.com> - 2015-05-26 11:14 +1200
                                  Re: Non-(sub)-standard C rick.c.hodgin@gmail.com - 2015-05-25 19:01 -0700
                                  Re: Non-(sub)-standard C James Kuyper <jameskuyper@verizon.net> - 2015-05-25 22:03 -0400
                          Re: Non-(sub)-standard C Richard Heathfield <rjh@cpax.org.uk> - 2015-05-25 10:40 +0100
                            Re: Non-(sub)-standard C Ian Collins <ian-news@hotmail.com> - 2015-05-25 22:50 +1200
                        Re: Non-(sub)-standard C David Brown <david.brown@hesbynett.no> - 2015-05-25 12:42 +0200
                          Re: Non-(sub)-standard C James Kuyper <jameskuyper@verizon.net> - 2015-05-25 19:00 -0400
                            Re: Non-(sub)-standard C David Brown <david.brown@hesbynett.no> - 2015-05-26 08:43 +0200
                      Re: Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-25 09:07 -0700
    Non-(sub)-standard C Chad <cdalten@gmail.com> - 2015-05-20 19:27 -0700

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

#62658

On Tuesday, May 26, 2015 at 2:01:56 PM UTC-4, David Kleinecke wrote:
> On Monday, May 25, 2015 at 10:19:41 AM UTC-7, rick.c...@gmail.com wrote:
> > That's one methodology which can be desirable on certain machines.
> > 
> > Are you aware of how stacks work? They are generally preferred
> > and make the mechanics you speak of a moot point.
>  
> You snipped too much so your post is not comprehendable.

It shows up on my mobile view, but not on desktop.  Interesting.
My apologies.

> Hardware stacks are not, a priori, available on every machine. But 
> stacks are easily created in software if needed.
> 
> Every list can be worked as a stack.

That one of my points / questions for you.  Why do you need them to
be defined a particular way?  The compiler can take any declaration
form given in source code and pull the same into a struct automatically
for internal use / wielding.  And even if they remain discrete elements,
on a stack you will have something like a pointer indicating the return
call address, with everything between that pointer and the current stack
pointer representing "a logical struct" of all local data, save anything
allocated using some type of stack-based alloc() function.

It doesn't seem necessary to have them manually pulled into a struct by
the developer.

Best regards,
Rick C. Hodgin

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

#62682

On Tuesday, May 26, 2015 at 11:40:08 AM UTC-7, rick.c...@gmail.com wrote:
> On Tuesday, May 26, 2015 at 2:01:56 PM UTC-4, David Kleinecke wrote:
> 
> > Hardware stacks are not, a priori, available on every machine. But 
> > stacks are easily created in software if needed.
> > 
> > Every list can be worked as a stack.
> 
> That one of my points / questions for you.  Why do you need them to
> be defined a particular way?  The compiler can take any declaration
> form given in source code and pull the same into a struct automatically
> for internal use / wielding.  And even if they remain discrete elements,
> on a stack you will have something like a pointer indicating the return
> call address, with everything between that pointer and the current stack
> pointer representing "a logical struct" of all local data, save anything
> allocated using some type of stack-based alloc() function.
> 
> It doesn't seem necessary to have them manually pulled into a struct by
> the developer.
 
You are describing what I would call the classical way to structure a
function. I don't know where or when it was invented but it is extremely
clever and useful. 

Now consider object-oriented coding. A classical function, as described,
can be viewed as creating an instance, using it in computation and
destroying the instance when it returns. In OOP the instance is persistent
and exists apart from a function call. The struct I described is the
instance data. I mentioned the easier way to do this but one could use
the space saving methods that are possible with stacked local data. 
However nowadays there is little reason to save space. 

In an event-oriented situation a function might be interrupted at any
point in execution. Not only must the execution point be saved but also
the current instance data. But there is no orderly sequence of events
and the function data cannot be assumed to be at the top of any stack.
I am looking at threads as an event-oriented situation.

I look at OOP and events as programming situations - not things one
always uses but tools to use when suitable. I am still working on just
what situations that means.

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

#62691

On Wednesday, May 27, 2015 at 1:28:41 PM UTC-4, David Kleinecke wrote:
> On Tuesday, May 26, 2015 at 11:40:08 AM UTC-7, rick.c...@gmail.com wrote:
> > On Tuesday, May 26, 2015 at 2:01:56 PM UTC-4, David Kleinecke wrote:
> > 
> > > Hardware stacks are not, a priori, available on every machine. But 
> > > stacks are easily created in software if needed.
> > > 
> > > Every list can be worked as a stack.
> > 
> > That one of my points / questions for you.  Why do you need them to
> > be defined a particular way?  The compiler can take any declaration
> > form given in source code and pull the same into a struct automatically
> > for internal use / wielding.  And even if they remain discrete elements,
> > on a stack you will have something like a pointer indicating the return
> > call address, with everything between that pointer and the current stack
> > pointer representing "a logical struct" of all local data, save anything
> > allocated using some type of stack-based alloc() function.
> > 
> > It doesn't seem necessary to have them manually pulled into a struct by
> > the developer.
>  
> You are describing what I would call the classical way to structure a
> function. I don't know where or when it was invented but it is extremely
> clever and useful. 
> 
> Now consider object-oriented coding. A classical function, as described,
> can be viewed as creating an instance, using it in computation and
> destroying the instance when it returns. In OOP the instance is persistent
> and exists apart from a function call. The struct I described is the
> instance data. I mentioned the easier way to do this but one could use
> the space saving methods that are possible with stacked local data. 
> However nowadays there is little reason to save space. 
> 
> In an event-oriented situation a function might be interrupted at any
> point in execution. Not only must the execution point be saved but also
> the current instance data. But there is no orderly sequence of events
> and the function data cannot be assumed to be at the top of any stack.
> I am looking at threads as an event-oriented situation.
> 
> I look at OOP and events as programming situations - not things one
> always uses but tools to use when suitable. I am still working on just
> what situations that means.

I understand.  I just don't see the use in creating an instance of a
function which is persistent with its data.  For that you can use a
class and member functions which act on (more or less) exactly what
that is with its public and private data members.

GCC and MSVC extend the struct definition to allow member functions
as well, reversing the process, and making it be instance-desirable
without any changes to the language.

I just don't see the point apart from personal desire or convention.

Best regards,
Rick C. Hodgin

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

#62741

On Wednesday, May 27, 2015 at 11:13:13 AM UTC-7, rick.c...@gmail.com wrote:
> On Wednesday, May 27, 2015 at 1:28:41 PM UTC-4, David Kleinecke wrote:
> > On Tuesday, May 26, 2015 at 11:40:08 AM UTC-7, rick.c...@gmail.com wrote:
> > > On Tuesday, May 26, 2015 at 2:01:56 PM UTC-4, David Kleinecke wrote:
> > > 
> > > > Hardware stacks are not, a priori, available on every machine. But 
> > > > stacks are easily created in software if needed.
> > > > 
> > > > Every list can be worked as a stack.
> > > 
> > > That one of my points / questions for you.  Why do you need them to
> > > be defined a particular way?  The compiler can take any declaration
> > > form given in source code and pull the same into a struct automatically
> > > for internal use / wielding.  And even if they remain discrete elements,
> > > on a stack you will have something like a pointer indicating the return
> > > call address, with everything between that pointer and the current stack
> > > pointer representing "a logical struct" of all local data, save anything
> > > allocated using some type of stack-based alloc() function.
> > > 
> > > It doesn't seem necessary to have them manually pulled into a struct by
> > > the developer.
> >  
> > You are describing what I would call the classical way to structure a
> > function. I don't know where or when it was invented but it is extremely
> > clever and useful. 
> > 
> > Now consider object-oriented coding. A classical function, as described,
> > can be viewed as creating an instance, using it in computation and
> > destroying the instance when it returns. In OOP the instance is persistent
> > and exists apart from a function call. The struct I described is the
> > instance data. I mentioned the easier way to do this but one could use
> > the space saving methods that are possible with stacked local data. 
> > However nowadays there is little reason to save space. 
> > 
> > In an event-oriented situation a function might be interrupted at any
> > point in execution. Not only must the execution point be saved but also
> > the current instance data. But there is no orderly sequence of events
> > and the function data cannot be assumed to be at the top of any stack.
> > I am looking at threads as an event-oriented situation.
> > 
> > I look at OOP and events as programming situations - not things one
> > always uses but tools to use when suitable. I am still working on just
> > what situations that means.
> 
> I understand.  I just don't see the use in creating an instance of a
> function which is persistent with its data.  For that you can use a
> class and member functions which act on (more or less) exactly what
> that is with its public and private data members.
> 
> GCC and MSVC extend the struct definition to allow member functions
> as well, reversing the process, and making it be instance-desirable
> without any changes to the language.
> 
> I just don't see the point apart from personal desire or convention.
 
Remember this is C (specifically C90) not C++. I believe struct/union
members have always possibly been pointers to functions.

And, of course, it is all personal desire - I want to simplify the coding
of applications written in C (C90) and make them more readible and more
understandable.

A consistent set of conventions helps simplify the code. I'm not trying
to force anything on anyone. I'm just offering my solution to some
of what I see as problems and perhaps someone will find my solution
useful. No big deal.

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

#62742

On Thursday, May 28, 2015 at 3:20:31 PM UTC-4, David Kleinecke wrote:
> On Wednesday, May 27, 2015 at 11:13:13 AM UTC-7, rick.c...@gmail.com wrote:
> > On Wednesday, May 27, 2015 at 1:28:41 PM UTC-4, David Kleinecke wrote:
> > > On Tuesday, May 26, 2015 at 11:40:08 AM UTC-7, rick.c...@gmail.com wrote:
> > > > On Tuesday, May 26, 2015 at 2:01:56 PM UTC-4, David Kleinecke wrote:
> > > > 
> > > > > Hardware stacks are not, a priori, available on every machine. But 
> > > > > stacks are easily created in software if needed.
> > > > > 
> > > > > Every list can be worked as a stack.
> > > > 
> > > > That one of my points / questions for you.  Why do you need them to
> > > > be defined a particular way?  The compiler can take any declaration
> > > > form given in source code and pull the same into a struct automatically
> > > > for internal use / wielding.  And even if they remain discrete elements,
> > > > on a stack you will have something like a pointer indicating the return
> > > > call address, with everything between that pointer and the current stack
> > > > pointer representing "a logical struct" of all local data, save anything
> > > > allocated using some type of stack-based alloc() function.
> > > > 
> > > > It doesn't seem necessary to have them manually pulled into a struct by
> > > > the developer.
> > >  
> > > You are describing what I would call the classical way to structure a
> > > function. I don't know where or when it was invented but it is extremely
> > > clever and useful. 
> > > 
> > > Now consider object-oriented coding. A classical function, as described,
> > > can be viewed as creating an instance, using it in computation and
> > > destroying the instance when it returns. In OOP the instance is persistent
> > > and exists apart from a function call. The struct I described is the
> > > instance data. I mentioned the easier way to do this but one could use
> > > the space saving methods that are possible with stacked local data. 
> > > However nowadays there is little reason to save space. 
> > > 
> > > In an event-oriented situation a function might be interrupted at any
> > > point in execution. Not only must the execution point be saved but also
> > > the current instance data. But there is no orderly sequence of events
> > > and the function data cannot be assumed to be at the top of any stack.
> > > I am looking at threads as an event-oriented situation.
> > > 
> > > I look at OOP and events as programming situations - not things one
> > > always uses but tools to use when suitable. I am still working on just
> > > what situations that means.
> > 
> > I understand.  I just don't see the use in creating an instance of a
> > function which is persistent with its data.  For that you can use a
> > class and member functions which act on (more or less) exactly what
> > that is with its public and private data members.
> > 
> > GCC and MSVC extend the struct definition to allow member functions
> > as well, reversing the process, and making it be instance-desirable
> > without any changes to the language.
> > 
> > I just don't see the point apart from personal desire or convention.
>  
> Remember this is C (specifically C90) not C++. I believe struct/union
> members have always possibly been pointers to functions.
> 
> And, of course, it is all personal desire - I want to simplify the coding
> of applications written in C (C90) and make them more readible and more
> understandable.
> 
> A consistent set of conventions helps simplify the code. I'm not trying
> to force anything on anyone. I'm just offering my solution to some
> of what I see as problems and perhaps someone will find my solution
> useful. No big deal.

How about writing a translator to take existing C90 code and migrate
it to C++ where those things you pursue can be achieved without changing
the C standard?  Those who wish to migrate their code could use your
tool, and those who wish to remain in C90 could do so.

Just a thought.  But since it's personal desire for you, I agree
wholeheartedly with your interest and effort.  "Pray continue,
Inspector."

Best regards,
Rick C. Hodgin

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

#62798

On Thursday, May 28, 2015 at 12:26:34 PM UTC-7, rick.c...@gmail.com wrote:
> On Thursday, May 28, 2015 at 3:20:31 PM UTC-4, David Kleinecke wrote:
> > On Wednesday, May 27, 2015 at 11:13:13 AM UTC-7, rick.c...@gmail.com wrote:
> > > On Wednesday, May 27, 2015 at 1:28:41 PM UTC-4, David Kleinecke wrote:
> > > > On Tuesday, May 26, 2015 at 11:40:08 AM UTC-7, rick.c...@gmail.com wrote:
> > > > > On Tuesday, May 26, 2015 at 2:01:56 PM UTC-4, David Kleinecke wrote:
> > > > > 
> > > > > > Hardware stacks are not, a priori, available on every machine. But 
> > > > > > stacks are easily created in software if needed.
> > > > > > 
> > > > > > Every list can be worked as a stack.
> > > > > 
> > > > > That one of my points / questions for you.  Why do you need them to
> > > > > be defined a particular way?  The compiler can take any declaration
> > > > > form given in source code and pull the same into a struct automatically
> > > > > for internal use / wielding.  And even if they remain discrete elements,
> > > > > on a stack you will have something like a pointer indicating the return
> > > > > call address, with everything between that pointer and the current stack
> > > > > pointer representing "a logical struct" of all local data, save anything
> > > > > allocated using some type of stack-based alloc() function.
> > > > > 
> > > > > It doesn't seem necessary to have them manually pulled into a struct by
> > > > > the developer.
> > > >  
> > > > You are describing what I would call the classical way to structure a
> > > > function. I don't know where or when it was invented but it is extremely
> > > > clever and useful. 
> > > > 
> > > > Now consider object-oriented coding. A classical function, as described,
> > > > can be viewed as creating an instance, using it in computation and
> > > > destroying the instance when it returns. In OOP the instance is persistent
> > > > and exists apart from a function call. The struct I described is the
> > > > instance data. I mentioned the easier way to do this but one could use
> > > > the space saving methods that are possible with stacked local data. 
> > > > However nowadays there is little reason to save space. 
> > > > 
> > > > In an event-oriented situation a function might be interrupted at any
> > > > point in execution. Not only must the execution point be saved but also
> > > > the current instance data. But there is no orderly sequence of events
> > > > and the function data cannot be assumed to be at the top of any stack.
> > > > I am looking at threads as an event-oriented situation.
> > > > 
> > > > I look at OOP and events as programming situations - not things one
> > > > always uses but tools to use when suitable. I am still working on just
> > > > what situations that means.
> > > 
> > > I understand.  I just don't see the use in creating an instance of a
> > > function which is persistent with its data.  For that you can use a
> > > class and member functions which act on (more or less) exactly what
> > > that is with its public and private data members.
> > > 
> > > GCC and MSVC extend the struct definition to allow member functions
> > > as well, reversing the process, and making it be instance-desirable
> > > without any changes to the language.
> > > 
> > > I just don't see the point apart from personal desire or convention.
> >  
> > Remember this is C (specifically C90) not C++. I believe struct/union
> > members have always possibly been pointers to functions.
> > 
> > And, of course, it is all personal desire - I want to simplify the coding
> > of applications written in C (C90) and make them more readible and more
> > understandable.
> > 
> > A consistent set of conventions helps simplify the code. I'm not trying
> > to force anything on anyone. I'm just offering my solution to some
> > of what I see as problems and perhaps someone will find my solution
> > useful. No big deal.
> 
> How about writing a translator to take existing C90 code and migrate
> it to C++ where those things you pursue can be achieved without changing
> the C standard?  Those who wish to migrate their code could use your
> tool, and those who wish to remain in C90 could do so.
> 
> Just a thought.  But since it's personal desire for you, I agree
> wholeheartedly with your interest and effort.  "Pray continue,
> Inspector."

I don't think a tool is needed. If I am using gcc I change the switch
from C to C++. Everytime I have done this I can't remember making any
changes at all but I understand there are a few differences. I would
expect them to be easily fixable by hand.

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

#62809

On Friday, May 29, 2015 at 2:12:58 PM UTC-3, David Kleinecke wrote:

<snip>

> I don't think a tool is needed. 

This has been controversial for many years.  While
many maintain that
porting from C to C++ should be easy, there have also
been people who have said real life porting of C
to C++ is distinctly non-trivial.

The fact that no tool exists says that either one
is not necessary, or that porting code from
C to C++ is not much of a priority.

-William Hughes

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

#62657

On Monday, May 25, 2015 at 12:01:43 PM UTC-4, David Kleinecke wrote:
> I want to put them into a struct so I can work with that struct as an
> object instance. It is also useful in a threading context as a piece of
> thread data. If a function is executing and the same function is called
> again with higher priority the code address and the current data must be
> saved. There are different models for threading but I am exploring the
> case where the interrupted function's local data can be stored as a
> whole and structs seem to be the easiest way to configure such an action.

That's one methodology which can be desirable on certain machines.

Are you aware of how stacks work? They are generally preferred
and make the mechanics you speak of a moot point.

Best regards,
Rick C. Hodgin

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

#62548

David Kleinecke <dkleinecke@gmail.com> writes:
> On Saturday, May 23, 2015 at 2:38:28 PM UTC-7, Keith Thompson wrote:
[...]
>> If you want a language that's free of features that exist only for
>> backward compatibility, perhaps C is not the language for you.
>  
> I would retort: If you want a language stuffed with features, perhaps
> C is not the language for you.

It's interesting that you didn't have anything to say about the
rest of what I wrote.  One might assume that means you agree,
but I won't make that assumption.

> PS: I think `for (int i = 0; i < N; i ++)' is the only extension of
> C90 I have actually seen in use. I disagree with it for reasons far
> afield (I want to pull all declarations in a function - at any depth
> - up to the start of function body - in order to define them all as a 
> struct).

You've never seen long long int in use?  Variable-length arrays?
Flexible array members?  <stdint.h>?  Compound literals?
Designated initializers?  "//" comments?  Mixed declarations and
statements within a block?  Math functions that take float or long
dobule arguments?  _Bool and bool?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#62549

On 24/05/15 22:03, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:

<snip>

>> PS: I think `for (int i = 0; i < N; i ++)' is the only extension of
>> C90 I have actually seen in use. I disagree with it for reasons far
>> afield (I want to pull all declarations in a function - at any depth
>> - up to the start of function body - in order to define them all as a
>> struct).
>
> You've never seen long long int in use?  Variable-length arrays?
> Flexible array members?  <stdint.h>?  Compound literals?
> Designated initializers?  "//" comments?  Mixed declarations and
> statements within a block?  Math functions that take float or long
> dobule arguments?  _Bool and bool?

Of the above list, in production code I've seen // comments (notably in 
a math.h header, causing the (C90) implementation to diagnose its own 
code!), and I think that's all. Of course, comp.lang.c is another 
matter, but it is a very artificial code environment.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#62578

Richard Heathfield wrote:
> On 24/05/15 22:03, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>
> <snip>
>
>>> PS: I think `for (int i = 0; i < N; i ++)' is the only extension of
>>> C90 I have actually seen in use. I disagree with it for reasons far
>>> afield (I want to pull all declarations in a function - at any depth
>>> - up to the start of function body - in order to define them all as a
>>> struct).
>>
>> You've never seen long long int in use?  Variable-length arrays?
>> Flexible array members?  <stdint.h>?  Compound literals?
>> Designated initializers?  "//" comments?  Mixed declarations and
>> statements within a block?  Math functions that take float or long
>> dobule arguments?  _Bool and bool?
>
> Of the above list, in production code I've seen // comments (notably in
> a math.h header, causing the (C90) implementation to diagnose its own
> code!), and I think that's all. Of course, comp.lang.c is another
> matter, but it is a very artificial code environment.

So you've never worked in a POSIX environment or worked on a Unix or 
Linux kernel?

-- 
Ian Collins

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

#62579

On 05/25/2015 12:46 AM, Ian Collins wrote:
> Richard Heathfield wrote:
>> On 24/05/15 22:03, Keith Thompson wrote:
...
>>> You've never seen long long int in use?  Variable-length arrays?
>>> Flexible array members?  <stdint.h>?  Compound literals?
>>> Designated initializers?  "//" comments?  Mixed declarations and
>>> statements within a block?  Math functions that take float or long
>>> dobule arguments?  _Bool and bool?
>>
>> Of the above list, in production code I've seen // comments (notably in
>> a math.h header, causing the (C90) implementation to diagnose its own
>> code!), and I think that's all. Of course, comp.lang.c is another
>> matter, but it is a very artificial code environment.
> 
> So you've never worked in a POSIX environment ...

I work in a POSIX environment, and am still constrained, in much of my
work, by a coding standard that was written in 1993 that requires me to
write C94 (== C90 + 2 TCs) code. I don't remember ever running into any
POSIX feature that I needed to use which required or depended upon the
new features added in C99. Could you give an example?

> ... or worked on a Unix or 
> Linux kernel?

That's not particularly odd - I think it's safe to assume that most
programmers haven't done kernel programming, even among the ones who
work on Unix-like systems.
-- 
James Kuyper

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

#62581

James Kuyper wrote:
> On 05/25/2015 12:46 AM, Ian Collins wrote:
>> Richard Heathfield wrote:
>>> On 24/05/15 22:03, Keith Thompson wrote:
> ....
>>>> You've never seen long long int in use?  Variable-length arrays?
>>>> Flexible array members?  <stdint.h>?  Compound literals?
>>>> Designated initializers?  "//" comments?  Mixed declarations and
>>>> statements within a block?  Math functions that take float or long
>>>> dobule arguments?  _Bool and bool?
>>>
>>> Of the above list, in production code I've seen // comments (notably in
>>> a math.h header, causing the (C90) implementation to diagnose its own
>>> code!), and I think that's all. Of course, comp.lang.c is another
>>> matter, but it is a very artificial code environment.
>>
>> So you've never worked in a POSIX environment ...
>
> I work in a POSIX environment, and am still constrained, in much of my
> work, by a coding standard that was written in 1993 that requires me to
> write C94 (== C90 + 2 TCs) code. I don't remember ever running into any
> POSIX feature that I needed to use which required or depended upon the
> new features added in C99. Could you give an example?

POSIX uses C99 and the types from <stdint.h> are frequently used.

>> ... or worked on a Unix or
>> Linux kernel?
>
> That's not particularly odd - I think it's safe to assume that most
> programmers haven't done kernel programming, even among the ones who
> work on Unix-like systems.

But they are likely to have at least seen some code...

-- 
Ian Collins

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

#62590

On 25/05/15 07:08, Ian Collins wrote:
> James Kuyper wrote:
>> On 05/25/2015 12:46 AM, Ian Collins wrote:
>
>>> ... or worked on a Unix or
>>> Linux kernel?
>>
>> That's not particularly odd - I think it's safe to assume that most
>> programmers haven't done kernel programming, even among the ones who
>> work on Unix-like systems.
>
> But they are likely to have at least seen some code...

In the days when the midday sun still lingered long over the southern 
hills, when the fruit still hung low on every tree, when a man could 
stretch his wheels from his table to his desk and back without hitting a 
single traffic queue, yes, reader, I pored over kernel code.
I was searching for enlightenment. I was searching for grace. I was 
searching for elegance. I don't really know what I sought. But what I 
found was a pig's breakfast. A sow's ear. A visual cacophony. I 
retreated in haste, since I lacked the requisite protective clothing. I 
decided there and then that I should consider Linux much as I consider 
Richmond sausages, which is to say that I should consider the heavenly 
aroma to be a blessing, and avoid peering too closely at the contents.

I hope things have got a little better in the intervening years (ouch, 
make that decades).

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#62600

On Monday, May 25, 2015 at 2:58:41 AM UTC-7, Richard Heathfield wrote:
> On 25/05/15 07:08, Ian Collins wrote:
> > James Kuyper wrote:
> >> On 05/25/2015 12:46 AM, Ian Collins wrote:
> >
> >>> ... or worked on a Unix or
> >>> Linux kernel?
> >>
> >> That's not particularly odd - I think it's safe to assume that most
> >> programmers haven't done kernel programming, even among the ones who
> >> work on Unix-like systems.
> >
> > But they are likely to have at least seen some code...
> 
> In the days when the midday sun still lingered long over the southern 
> hills, when the fruit still hung low on every tree, when a man could 
> stretch his wheels from his table to his desk and back without hitting a 
> single traffic queue, yes, reader, I pored over kernel code.
> I was searching for enlightenment. I was searching for grace. I was 
> searching for elegance. I don't really know what I sought. But what I 
> found was a pig's breakfast. A sow's ear. A visual cacophony. I 
> retreated in haste, since I lacked the requisite protective clothing. I 
> decided there and then that I should consider Linux much as I consider 
> Richmond sausages, which is to say that I should consider the heavenly 
> aroma to be a blessing, and avoid peering too closely at the contents.
> 
> I hope things have got a little better in the intervening years (ouch, 
> make that decades).
 
I had the same experience with the kernel - even when I sought the help
of an entire book explaining it. I could follow little parts in detail
but the whole remained mysterious. 

 

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

#62621

On 05/25/2015 02:08 AM, Ian Collins wrote:
> James Kuyper wrote:
>> On 05/25/2015 12:46 AM, Ian Collins wrote:
...
>>> So you've never worked in a POSIX environment ...
>>
>> I work in a POSIX environment, and am still constrained, in much of my
>> work, by a coding standard that was written in 1993 that requires me to
>> write C94 (== C90 + 2 TCs) code. I don't remember ever running into any
>> POSIX feature that I needed to use which required or depended upon the
>> new features added in C99. Could you give an example?
> 
> POSIX uses C99 and the types from <stdint.h> are frequently used.

In the external interfaces? I can't remember ever seeing one whose
interface involved a size-named type. Can you give me some examples?
While my code is allowed to rely upon POSIX, by it's very nature my code
has a few calls to actual POSIX routines - so it would be easy for me to
miss.

>>> ... or worked on a Unix or
>>> Linux kernel?
>>
>> That's not particularly odd - I think it's safe to assume that most
>> programmers haven't done kernel programming, even among the ones who
>> work on Unix-like systems.
> 
> But they are likely to have at least seen some code...

I've been working on unix-like systems on-and-off since 1979, and
continuously since 1996, and I don't think I've ever had any need to
look at kernel code. If I did have a need, I wasn't aware of that need,
so I've never actually seen any.
-- 
James Kuyper

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

#62624

James Kuyper wrote:
> On 05/25/2015 02:08 AM, Ian Collins wrote:
>> James Kuyper wrote:
>>> On 05/25/2015 12:46 AM, Ian Collins wrote:
> ....
>>>> So you've never worked in a POSIX environment ...
>>>
>>> I work in a POSIX environment, and am still constrained, in much of my
>>> work, by a coding standard that was written in 1993 that requires me to
>>> write C94 (== C90 + 2 TCs) code. I don't remember ever running into any
>>> POSIX feature that I needed to use which required or depended upon the
>>> new features added in C99. Could you give an example?
>>
>> POSIX uses C99 and the types from <stdint.h> are frequently used.
>
> In the external interfaces? I can't remember ever seeing one whose
> interface involved a size-named type. Can you give me some examples?

The obvious examples are the network byte ordering functions.  They also 
pop up in other network related functions.

>>>> ... or worked on a Unix or
>>>> Linux kernel?
>>>
>>> That's not particularly odd - I think it's safe to assume that most
>>> programmers haven't done kernel programming, even among the ones who
>>> work on Unix-like systems.
>>
>> But they are likely to have at least seen some code...
>
> I've been working on unix-like systems on-and-off since 1979, and
> continuously since 1996, and I don't think I've ever had any need to
> look at kernel code. If I did have a need, I wasn't aware of that need,
> so I've never actually seen any.

In my case, it's either been modifying drivers or tracking bugs.  I'm 
surprised someone who has been working on Unix-like systems for so long 
hasn't been tempted to fix the occasional bug!

-- 
Ian Collins

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

#62625

On Monday, May 25, 2015 at 7:14:30 PM UTC-4, Ian Collins wrote:
> In my case, it's either been modifying drivers or tracking bugs.  I'm 
> surprised someone who has been working on Unix-like systems for so long 
> hasn't been tempted to fix the occasional bug!

Ian, you could stop by http://www.gnu.org/software/hurd/hurd.html and
fix a bug or two. :-)

Best regards,
Rick C. Hodgin 

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

#62626

On 05/25/2015 07:14 PM, Ian Collins wrote:
> James Kuyper wrote:
...
>> I've been working on unix-like systems on-and-off since 1979, and
>> continuously since 1996, and I don't think I've ever had any need to
>> look at kernel code. If I did have a need, I wasn't aware of that need,
>> so I've never actually seen any.
> 
> In my case, it's either been modifying drivers or tracking bugs.  I'm 
> surprised someone who has been working on Unix-like systems for so long 
> hasn't been tempted to fix the occasional bug!

If I had found something that was unambiguously a bug in the kernel, I
wouldn't have had permission to attempt to fix it - that would have been
the SA's responsibility. On my home system I have Ubuntu Linux
installed, and of necessity I am the SA  - but I'm far less than expert
at that role. I've found lots of bugs in my own code, more in other
people's code, a fair number of bugs in third party libraries, and one
gcc bug, but I've never identified a kernel defect as such. It's
possible that some of the problems that I did report to the SAs were
fixed by patches to the kernel, but I was never informed of anything
like that.
-- 
James Kuyper

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

#62588

On 25/05/15 05:46, Ian Collins wrote:
> Richard Heathfield wrote:
>> On 24/05/15 22:03, Keith Thompson wrote:
<snip>
>>> You've never seen long long int in use?  Variable-length arrays?
>>> Flexible array members?  <stdint.h>?  Compound literals?
>>> Designated initializers?  "//" comments?  Mixed declarations and
>>> statements within a block?  Math functions that take float or long
>>> dobule arguments?  _Bool and bool?
>>
>> Of the above list, in production code I've seen // comments (notably in
>> a math.h header, causing the (C90) implementation to diagnose its own
>> code!), and I think that's all. Of course, comp.lang.c is another
>> matter, but it is a very artificial code environment.
>
> So you've never worked in a POSIX environment or worked on a Unix or
> Linux kernel?

In C++, sure, but we were talking about C. Most of my C programming (not 
/quite/ all, but certainly most) is done in environments where 
portability matters a great deal.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

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

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

csiph-web