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

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

Learning C as an existing programmer

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

Contents

  Learning C as an existing programmer rammy <nospam@nospam.com> - 2012-06-24 21:52 +0000
    Re: Learning C as an existing programmer Ian Collins <ian-news@hotmail.com> - 2012-06-25 10:26 +1200
      Re: Learning C as an existing programmer "Charles Richmond" <numerist@aquaporin4.com> - 2012-06-24 18:28 -0500
        Re: Learning C as an existing programmer "Joe." <antelope3@news.net> - 2012-06-25 01:05 -0600
        Re: Learning C as an existing programmer "Joe." <antelope3@news.net> - 2012-06-25 01:10 -0600
          Re: Learning C as an existing programmer Weland <weland@faeroes.freeshell.org> - 2012-06-25 08:20 +0000
            Re: Learning C as an existing programmer "Joe." <antelope3@news.net> - 2012-07-02 01:46 -0600
        Re: Learning C as an existing programmer Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2012-06-25 20:37 +0000
          Re: Learning C as an existing programmer James Kuyper <jameskuyper@verizon.net> - 2012-06-25 16:51 -0400
          Re: Learning C as an existing programmer Keith Thompson <kst-u@mib.org> - 2012-06-25 14:25 -0700
            Re: Learning C as an existing programmer Les Cargill <lcargill99@comcast.com> - 2012-06-25 17:50 -0500
            Re: Learning C as an existing programmer William Ahern <william@wilbur.25thandClement.com> - 2012-06-25 16:52 -0700
          Re: Learning C as an existing programmer Les Cargill <lcargill99@comcast.com> - 2012-06-25 17:49 -0500
          Re: Learning C as an existing programmer nick_keighley_nospam@hotmail.com - 2012-06-26 00:09 -0700
      Re: Learning C as an existing programmer "Joe." <antelope3@news.net> - 2012-06-25 00:55 -0600
      Re: Learning C as an existing programmer Nachy <mazwolfe@gmail.com> - 2012-06-25 13:26 -0700
        Re: Learning C as an existing programmer James Kuyper <jameskuyper@verizon.net> - 2012-06-25 17:07 -0400
        Re: Learning C as an existing programmer Nachy <mazwolfe@gmail.com> - 2012-06-25 14:56 -0700
          Re: Learning C as an existing programmer James Kuyper <jameskuyper@verizon.net> - 2012-06-25 18:29 -0400
          Re: Learning C as an existing programmer pete <pfiland@mindspring.com> - 2012-06-25 18:56 -0400
            Re: Learning C as an existing programmer nick_keighley_nospam@hotmail.com - 2012-06-26 00:21 -0700
              Re: Learning C as an existing programmer Robert Wessel <robertwessel2@yahoo.com> - 2012-06-26 02:56 -0500
              Re: Learning C as an existing programmer Ike Naar <ike@sverige.freeshell.org> - 2012-06-26 08:10 +0000
          Re: Learning C as an existing programmer "J. J. Farrell" <jjf@bcs.org.uk> - 2012-06-26 07:06 +0100
        Re: Learning C as an existing programmer nick_keighley_nospam@hotmail.com - 2012-06-26 00:18 -0700
          Re: Learning C as an existing programmer Keith Thompson <kst-u@mib.org> - 2012-06-26 00:23 -0700
          Re: Learning C as an existing programmer James Kuyper <jameskuyper@verizon.net> - 2012-06-26 06:47 -0400
    Re: Learning C as an existing programmer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-25 01:21 +0100
    Re: Learning C as an existing programmer "Joe." <antelope3@news.net> - 2012-06-25 00:54 -0600
    Re: Learning C as an existing programmer David Brown <david@westcontrol.removethisbit.com> - 2012-06-25 09:19 +0200
      Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-06-25 11:15 +0100
        Re: Learning C as an existing programmer "Ronald Benedik" <Aon.912717285@aon.at> - 2012-06-25 12:30 +0200
          Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-06-25 11:43 +0100
            Re: Learning C as an existing programmer "Ronald Benedik" <Aon.912717285@aon.at> - 2012-06-25 12:55 +0200
        Re: Learning C as an existing programmer Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-06-25 10:38 +0000
          Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-06-25 13:05 +0100
        Re: Learning C as an existing programmer Heikki Kallasjoki <fis+usenet@zem.fi> - 2012-06-25 10:56 +0000
        Re: Learning C as an existing programmer David Brown <david@westcontrol.removethisbit.com> - 2012-06-25 13:34 +0200
          Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-06-25 12:43 +0100
            Re: Learning C as an existing programmer David Brown <david@westcontrol.removethisbit.com> - 2012-06-25 15:16 +0200
              Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-06-25 14:39 +0100
                Re: Learning C as an existing programmer David Brown <david@westcontrol.removethisbit.com> - 2012-06-26 11:07 +0200
                  Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-06-26 12:05 +0100
                    Re: Learning C as an existing programmer David Brown <david@westcontrol.removethisbit.com> - 2012-06-26 14:28 +0200
              Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-06-25 14:39 +0100
      Re: Learning C as an existing programmer 88888 Dihedral <dihedral88888@googlemail.com> - 2012-06-25 18:21 -0700
        Re: Learning C as an existing programmer David Brown <david@westcontrol.removethisbit.com> - 2012-06-26 11:03 +0200
    Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-25 00:50 -0700
      Re: Learning C as an existing programmer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-25 11:50 +0100
        Re: Learning C as an existing programmer gwowen <gwowen@gmail.com> - 2012-06-25 04:32 -0700
          Re: Learning C as an existing programmer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-25 14:25 +0100
            Re: Learning C as an existing programmer gwowen <gwowen@gmail.com> - 2012-06-26 02:38 -0700
              Re: Learning C as an existing programmer jacob navia <jacob@spamsink.net> - 2012-06-26 12:13 +0200
                Re: Learning C as an existing programmer jacob navia <jacob@spamsink.net> - 2012-06-26 12:15 +0200
                Re: Learning C as an existing programmer Ian Collins <ian-news@hotmail.com> - 2012-06-26 23:08 +1200
              Re: Learning C as an existing programmer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-27 01:55 +0100
                Re: Learning C as an existing programmer 88888 Dihedral <dihedral88888@googlemail.com> - 2012-06-26 18:43 -0700
          Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-25 14:27 -0700
            Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-26 00:18 -0700
              Re: Learning C as an existing programmer nick_keighley_nospam@hotmail.com - 2012-06-26 04:02 -0700
              Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-26 05:54 -0700
                Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-26 07:22 -0700
                  Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-28 04:28 -0700
                    Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-29 10:07 -0700
                      Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-02 08:57 -0700
                        Re: Learning C as an existing programmer gwowen <gwowen@gmail.com> - 2012-07-03 03:26 -0700
                          Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-06 16:28 -0700
                        Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-06 18:16 -0700
                          Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-07 04:51 -0700
                            Re: Learning C as an existing programmer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-07 16:48 +0100
                              Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-07 09:07 -0700
                            Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-07 12:27 -0700
                Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-07-03 15:01 +0100
                  Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-06 16:13 -0700
                    Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-07-07 19:35 +0100
                      Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-07 11:52 -0700
                      Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-07 19:40 -0700
            Re: Learning C as an existing programmer gwowen <gwowen@gmail.com> - 2012-06-26 03:03 -0700
              Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-26 06:34 -0700
              Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-26 06:40 -0700
              Re: Learning C as an existing programmer Gareth Owen <gwowen@gmail.com> - 2012-06-27 07:16 +0100
                Re: Learning C as an existing programmer James Kuyper <jameskuyper@verizon.net> - 2012-06-27 06:48 -0400
              Re: Learning C as an existing programmer "io_x" <a@b.c.invalid> - 2012-06-28 09:18 +0200
                Re: Learning C as an existing programmer nick_keighley_nospam@hotmail.com - 2012-06-28 02:02 -0700
                  Re: Learning C as an existing programmer "io_x" <a@b.c.invalid> - 2012-06-28 12:19 +0200
            Re: Learning C as an existing programmer Rui Maciel <rui.maciel@gmail.com> - 2012-07-03 15:00 +0100
              Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-06 15:56 -0700
                Re: Learning C as an existing programmer Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-07 09:18 -0700
                  Re: Learning C as an existing programmer Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-07 11:56 -0700

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

#22847

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> gwowen <gwowen@gmail.com> writes:
>>Well, yes.  But you could say the same for NULL pointer dereferences.
>
>   One can always guard: »if(p)*p;«, I am not aware of the corresponding
>   guard for VLAs.

Well, that was sort of my original point.

>   The spelling of N1570 is »null pointer« (not »NULL pointer«).

I am not a standardisation document.

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

#22857

On 06/27/2012 02:16 AM, Gareth Owen wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
> 
>> gwowen <gwowen@gmail.com> writes:
>>> Well, yes.  But you could say the same for NULL pointer dereferences.
>>
>>   One can always guard: »if(p)*p;«, I am not aware of the corresponding
>>   guard for VLAs.
> 
> Well, that was sort of my original point.
> 
>>   The spelling of N1570 is »null pointer« (not »NULL pointer«).
> 
> I am not a standardisation document.

Yes, but you are someone who's trying to communicate meaningfully about
C. Using correct terminology when doing so improves your chances of
being understood correctly.
-- 
James Kuyper

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

#22914

"Stefan Ram" <ram@zedat.fu-berlin.de> ha scritto nel messaggio
news:null-pointer-
20120626132947@ram.dialup.fu-berlin.de...

de germania?

> gwowen <gwowen@gmail.com> writes:
>>Well, yes.  But you could say the same for NULL pointer dereferences.
>
>  One can always guard: »if(p)*p;«, I am not aware of the corresponding
>  guard for VLAs.
>
>  The spelling of N1570 is »null pointer« (not »NULL pointer«).

char  *p;

in some place i write...
p=0; *p=0;
do you think it is not good?

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

#22919

On Thursday, June 28, 2012 8:18:37 AM UTC+1, io_x wrote:


> char  *p;
> 
> in some place i write...
> p=0; *p=0;
> do you think it is not good?

dunno. what effect were you hoping for? If there's any sort of memory management it'll likely crash.

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

#22922

<nick_keighley_nospam@hotmail.com> ha scritto nel messaggio 
news:11249137-7f5e-410f-9baa-a0e46bf54ac7@googlegroups.com...
> On Thursday, June 28, 2012 8:18:37 AM UTC+1, io_x wrote:
>
>
>> char  *p;
>>
>> in some place i write...
>> p=0; *p=0;
>> do you think it is not good?
>
> dunno. what effect were you hoping for? If there's any sort of memory 
> management it'll likely crash.

i search one crash in that point
yes it is wrong to use that, it is not portable,
but better than doing nothing...
i not like abort() etc because i never used it 

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

#23081

Tim Rentsch wrote:

> What you mean is that VLAs have no portably guaranteed failure
> mechanism.  On a particular implementation they may very well
> have a well-defined, implementation-supplied, such mechanism.

Is there any implementation that actually implements such a mechanism?  And 
if this sort of mechanism isn't required by the standard, is it a good idea 
to write code counting on it?


Rui Maciel

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

#23115

Rui Maciel <rui.maciel@gmail.com> writes:

> Tim Rentsch wrote:
>
>> What you mean is that VLAs have no portably guaranteed failure
>> mechanism.  On a particular implementation they may very well
>> have a well-defined, implementation-supplied, such mechanism.
>
> Is there any implementation that actually implements such
> a mechanism?

I don't know.  On the other hand, I don't know if there is
any implementation that faithfully implements array bounds
checking (ie, for C), yet such implementations are often
brought up in newsgroup postings;  moreover the mechanism
that I suggested for detecting VLA allocation failure is
much easier to add to an implementation than support for
array bounds checking is.

> And if this sort of mechanism isn't required by the standard,
> is it a good idea to write code counting on it?

That depends on the context for which the code is being
written.  Almost all programs that I write, or work on,
make some assumptions about the environment(s) in which
they will run.  I don't see anything wrong with relying
on a platform-specific capability if the nature of the
problem being solved means it is going to be run only
on platforms that support the capability.  Furthermore,
the particular mechanism I suggested is completely safe
in the sense that it does no harm in an implementation
that does not support it.  To me it makes more sense,
assuming the associated costs of the extra code aren't
too high, to include code that helps on some platforms
and is essentially ignored on others.  Certainly there
are cases where maximum portability is paramount, and
in such cases we might want to avoid even a hint of any
platform-specific features;  I expect, though, that it
is more common for programs to be closer to the other
end of the spectrum, targeting a particular platform or
a small number of related platforms, and in those cases
the benefits (ie, of using a non-ubiquitous capability)
are more likely to outweigh the costs.  As usual there
is no hard-and-fast rule that's always right, and what
makes sense in one case might be a very poor decision
in another.  (Like a friend of mine used to say: "I've
found a way to eliminate tradeoffs; the only thing is,
you have to give up something else...")

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

#23168

בתאריך יום שישי, 6 ביולי 2012 23:56:34 UTC+1, מאת Tim Rentsch:
> I expect, though, that it
> is more common for programs to be closer to the other
> end of the spectrum, targeting a particular platform or
> a small number of related platforms, and in those cases
> the benefits (ie, of using a non-ubiquitous capability)
> are more likely to outweigh the costs.  
>
Most programs don't have to run on more than a limited set of platforms, often just one.
But most components can be written portably. Basically you need to ask, does this bit of funtionality perform IO? If not, it can be written in pure ANSI C, and normally it should be written in pure ANSI C. There is a problem with malloc(), and there are some side issues with DMA engines and the like which blur the distinction between IO and processing.
With some embedded programs the calculation side of what they do is so trivial that this isn't of any real use. Essentially the whole program is about interacting with the various ports, with just a bit of logic to hold it all together. But a lot of programs are the opposite, mainly calculation with a trvial bit of IO to get the data in and pass the results back.

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

#23180

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> Tim Rentsch:
>> I expect, though, that it
>> is more common for programs to be closer to the other
>> end of the spectrum, targeting a particular platform or
>> a small number of related platforms, and in those cases
>> the benefits (ie, of using a non-ubiquitous capability)
>> are more likely to outweigh the costs.  
>>
>
> Most programs don't have to run on more than a limited set of
> platforms, often just one.
>
> But most components can be written portably. Basically you need to
> ask, does this bit of funtionality perform IO? If not, it can be
> written in pure ANSI C, and normally it should be written in pure ANSI
> C. There is a problem with malloc(), and there are some side issues
> with DMA engines and the like which blur the distinction between IO
> and processing.  [snip elaboration]

I might have to be concerned about that, if what I was
talking about had to do with writing portable components.
But it wasn't.

[toc] | [prev] | [standalone]

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

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

csiph-web