twitter: comp.lang.c - 25 new messages in 8 topics

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

comp.lang.c@googlegroups.com

Today's topics:

* 16:32 far pointers in OpenWatcom C/C++ - 10 messages, 4 authors
http://groups.google.com/group/comp.lang.c/t/4728dadef590aafe?hl=en
* Equality failure in <=. - 4 messages, 4 authors
http://groups.google.com/group/comp.lang.c/t/d49ffc1284d3557d?hl=en
* Hoping not to do the ugly - 4 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/8055111701d1781b?hl=en
* Reading lines from a text file - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/5d6be78418b75b97?hl=en
* Has thought been given given to a cleaned up C? Possibly called C+. - 3
messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en
* Why doesn't fscanf fail when it doesn't find ordinary characters (specified
in format) in the input? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/d2c05bf5fc6faf58?hl=en
* Casting jmp_buf to void * - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/a9e559468513ce12?hl=en
* Does GCC optimize variadic functions to death? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/00b2bccdde28fde4?hl=en

==============================================================================
TOPIC: 16:32 far pointers in OpenWatcom C/C++
http://groups.google.com/group/comp.lang.c/t/4728dadef590aafe?hl=en
==============================================================================

== 1 of 10 ==
Date: Wed, Mar 24 2010 3:03 pm
From: Branimir Maksimovic

On Wed, 24 Mar 2010 14:04:54 -0700
Keith Thompson <kst-u@mib.org> wrote:

>
> If you're talking about C, it's *very* important to remember that
> pointers are not integers, and integers are not pointers.

Well digital computer is all numbers. array of 1' and 0's.
Remember, C was meant for assembler programmers.
I first learned basic than assembler on spectrum 48kb.
Then somehow C compiler was available for spectrum,
so when I saw ++ operator, immediately recognized
C as another assembler. Especially was fascinated that
you could crash computer with it same as in assembler.
Technically pointers are integers, but understanding
their meaning and usage on particular implementation
and exploiting it is not portable, of course.
But you *can* do it anyway if necessary and portability
is not of concern.

>
> It's possible to convert between pointer and integer types, but the
> result of such a conversion (with the lone exception of converting a
> constant 0 to a pointer type) is not portable.
> [...]
>
> > I think, malloc guarantees largest segment
> > and ints are actually relative , short pointers into segment,
> > while you can still use absolute pointers as bases.
> > It's just a matter of realizing this.
>
> Sorry, I don't know what "malloc guarantees largest segment"
> is supposed to mean. The C standard, which is what defines the
> behavior of malloc, doesn't talk about segments. C is carefully
> designed to work on systems with either segmented or monolithic
> addressing spaces.

Yes but, when you malloc you get chunk of raw memory
that can be indexed by integers of any type.
This maps 1-1 on assembler thinkology ;)
What about memory bank switching model?
Eg on amstrad cpc6128 there was 128kb of ram,
but 8 memory banks of 16kb each.
CPU could address maximum of 64kb.
64kb linear address space for apps and shadow OS
in another 64 kb, CP/M ?
There is *real* C compiler for it.
My second home computer btw ;)

>
> > So for example if you have architecture base+ 12 bit offset like 360
> > you can't malloc more than 4kb because of absolute+relativep.
> > Since relativep in this case is 12 bits your size_t is limited to
> > 4096 bytes.
>
> A conforming hosted C implementation must support objects of at least
> 65535 bytes (in C99; C90 required 32767 bytes). So size_t must be at
> least 16 bits. It's up to the compiler to generate whatever code is
> needed to support this.

Thanks for explanation.

Greets!

--
http://maxa.homedns.org/

Sometimes online sometimes not

== 2 of 10 ==
Date: Wed, Mar 24 2010 3:08 pm
From: Seebs

On 2010-03-24, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
> On Wed, 24 Mar 2010 14:04:54 -0700
> Keith Thompson <kst-u@mib.org> wrote:
>> If you're talking about C, it's *very* important to remember that
>> pointers are not integers, and integers are not pointers.

> Well digital computer is all numbers. array of 1' and 0's.

Yes, but a pointer need not be a single number. It could be a pair
of numbers, one of which indicates a segment, and another of which
indicates an offset, and operations on that pointer could operate
entirely on the offset, for instance.

> Remember, C was meant for assembler programmers.

Yes.

> Technically pointers are integers,

No, they aren't.

They often happen to be isomorphic to integers on machines with a flat
addressing space, but they aren't always elsewhere. On a segmented
architecture, it's quite possible to have two different bit patterns
of "pointer" point to the same location.

> Yes but, when you malloc you get chunk of raw memory
> that can be indexed by integers of any type.

What do you mean "indexed by integers of any type"?

> This maps 1-1 on assembler thinkology ;)

Well, it might. It usually maps pretty well onto any given assembler, but
sometimes the mapping is very different between different C implementations.

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

== 3 of 10 ==
Date: Wed, Mar 24 2010 3:09 pm
From: Seebs

On 2010-03-24, Keith Thompson <kst-u@mib.org> wrote:
> Ahem A Rivet's Shot <steveo@eircom.net> writes:
>> It doesn't have to be a typedef - it usually is but it doesn't have
>> to be.

> How could size_t not be a typedef? It's not a keyword or a macro.

It could, however, be treated magically by the compiler.

Which means that, while it appears to necessarily have the same semantics
as a typedef, there's no requirement that it actually *is* one.

== 4 of 10 ==
Date: Wed, Mar 24 2010 4:22 pm
From: Phil Carmody

f/u set.

Ahem A Rivet's Shot <steveo@eircom.net> writes:
> On Wed, 24 Mar 2010 14:45:24 +0100
> Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>
>> On Wed, 24 Mar 2010 12:41:04 +0000
>> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>
>> > Only if they're big enough - nothing prevents a C
>> > implementation having no integer type bigger than 32 bits while
>> > pointers are (say) 48 bits.
>>
>> Problem is that integers are used to index into arrays.
>
> Well strictly speaking you need size_t in order to guarantee being
> able to index into any array.
>
>> Since arrays are identical to raw memory segment thanks to malloc,
>
> Nothing guarantees that.

Nothing even _defines_ what that means. 'Raw' and 'segment' have
simply been pulled out of an over-active imagination.

>> ints must have capability to index maximum array/segment
>> size on architecture. So actually long long would be
>> enough big for maximum relative indexing of segment.
>
> Nope size_t must be big enough for that, but there's no requirement
> that any int type be as big as size_t.

How else can there be a corresponding signed type? (n869 7.19.6.1)

>> Since pointer arithmetic in C is identical with
>> array indexing, plain ints are actually C pointers
>> with relative addressing ,
>
> No ints are not C pointers they have *very* different arithmetic
> rules.
>
>> while you p[revious explanation
>> shows that ordinary C pointers are actually absolute addressing
>> pointers with convenient syntax.
>> Actually implementation can identify any pointer with
>> int as they are identical to indexes into arrays,
>> but void* and char* has to be absolute addresses.
>
> Pointers do not have to be any kind of address.

The pointer which is a result of the & operator has to be a very
addressy kind of address.

Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1

== 5 of 10 ==
Date: Wed, Mar 24 2010 4:28 pm
From: Phil Carmody

Seebs <usenet-nospam@seebs.net> writes:
> On 2010-03-24, Keith Thompson <kst-u@mib.org> wrote:
>> Ahem A Rivet's Shot <steveo@eircom.net> writes:
>>> It doesn't have to be a typedef - it usually is but it doesn't have
>>> to be.
>
>> How could size_t not be a typedef? It's not a keyword or a macro.
>
> It could, however, be treated magically by the compiler.
>
> Which means that, while it appears to necessarily have the same semantics
> as a typedef, there's no requirement that it actually *is* one.

It has to be a 'type' which has a 'corresponding signed type', and it
has to be both 'declared' and 'defined'. Not many things can be all
of those.

Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1

== 6 of 10 ==
Date: Wed, Mar 24 2010 4:32 pm
From: Ben Bacarisse

Branimir Maksimovic <bmaxa@hotmail.com> writes:

> On Wed, 24 Mar 2010 14:04:54 -0700
> Keith Thompson <kst-u@mib.org> wrote:
>>
>> If you're talking about C, it's *very* important to remember that
>> pointers are not integers, and integers are not pointers.
>
> Well digital computer is all numbers. array of 1' and 0's.

Would you have made the same response if Keith had said "remember that
floating point numbers are not integers, and integers are not floating
point numbers"?

Sure, you can sometimes treat a region of storage as either an int or
a float, but doing so ignores what is important about the two types.

> Remember, C was meant for assembler programmers.
> I first learned basic than assembler on spectrum 48kb.
> Then somehow C compiler was available for spectrum,
> so when I saw ++ operator, immediately recognized
> C as another assembler. Especially was fascinated that
> you could crash computer with it same as in assembler.
> Technically pointers are integers, but understanding
> their meaning and usage on particular implementation
> and exploiting it is not portable, of course.

Technically, both pointers and integers are stored as collections of
bits, but it's a long way from that to say that pointers are
integers. The most useful view of a data type is what you can do with
it. The operations defined on integer types and pointer types (in C)
are very different.

<snip>
--
Ben.

== 7 of 10 ==
Date: Wed, Mar 24 2010 4:40 pm
From: Phil Carmody

Dann Corbit <dcorbit@connx.com> writes:
> In article <1e27d5ee-a1b1-45d9-9188-
> 63ab37398e9f@d37g2000yqn.googlegroups.com>,
> nick_keighley_nospam@hotmail.com says...
>>
>> On 23 Mar, 20:56, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> > In alt.sys.pdp10 Richard Bos <ralt...@xs4all.nl> wrote:
>> > (snip)
>> >
>> > > That crossposting was, for once, not asinine. It served as a nice
>> > > example why, even now, Leenux weenies are not correct when they insist
>> > > that C has a flat memory model and all pointers are just numbers.
>> >
>> > Well, you could also read the C standard to learn that.
>>
>> but if you say that you get accused of language lawyering.
>> "Since IBM stopped making 360s no C program ever needs to run on such
>> a platform"
>
> We have customers who are running their business on harware from the mid
> 1980s. It may sound ludicrous, but it if solves all of their business
> needs, and runs solid 24x365, why should they upgrade?

Because they could run an equivalently computationally powerful
solution with various levels of redundancy and fail-over protection,
with a power budget sensibly measured in mere Watts?

Phil, who has customers who prefer systems consuming <20 mW.
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1

== 8 of 10 ==
Date: Wed, Mar 24 2010 4:44 pm
From: Phil Carmody

Walter Bushell <proto@panix.com> writes:
> Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>> Problem is that segmented memory model is much better when working
>> with 64 bit address space. Flat memory model wastes to much
>> RAM. It would be better for standard C and C++ to provide appropriate
>> pointer semantics in order to keep memory usage optimal.
>> What is use of 64 bit flat pointers when you can actually
>> just load segment base and work with offsets?
...
> But ram is *so* cheap these days. Can you think of a reason for a
> million pointers at once? And that would be 0.008 gigabytes. Perhaps one
> needs to be that conscious for embedded work, but then one is not
> working with 64 bit addressing either.

64-bit Alpha, POWER, and MIPS architectures have been used in
embedded applications, complete with their native 64-bit
addressing.

Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1

== 9 of 10 ==
Date: Wed, Mar 24 2010 4:47 pm
From: Phil Carmody

Branimir Maksimovic <bmaxa@hotmail.com> writes:
> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
>> No, a very small fraction of the virtual address space is mapped to
>> physical RAM.
>
> Hm , why then people have problem with Linux OOM killer,

Because they are using vastly more virtual address space
than there is physical RAM. Which kinda follows from what
Joe already said.

Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1

== 10 of 10 ==
Date: Wed, Mar 24 2010 5:15 pm
From: Ben Bacarisse

Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:

> Seebs <usenet-nospam@seebs.net> writes:
>> On 2010-03-24, Keith Thompson <kst-u@mib.org> wrote:
>>> Ahem A Rivet's Shot <steveo@eircom.net> writes:
>>>> It doesn't have to be a typedef - it usually is but it doesn't have
>>>> to be.
>>
>>> How could size_t not be a typedef? It's not a keyword or a macro.
>>
>> It could, however, be treated magically by the compiler.
>>
>> Which means that, while it appears to necessarily have the same semantics
>> as a typedef, there's no requirement that it actually *is* one.
>
> It has to be a 'type' which has a 'corresponding signed type',

I can't find this requirement. Where does it come from?

(The reverse: that for every signed integer type there is a
corresponding unsigned integer type is certainly true).

> and it
> has to be both 'declared' and 'defined'. Not many things can be all
> of those.

All sorts of magic might be involved:

__declare__and__define('size_t', '48 bits');

or maybe the type just pops into existence when one of the appropriate
header files is seen, but in most cases there is no reason not to use
a typedef.

--
Ben.

==============================================================================
TOPIC: Equality failure in <=.
http://groups.google.com/group/comp.lang.c/t/d49ffc1284d3557d?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Mar 24 2010 3:12 pm
From: Seebs

On 2010-03-24, Robbie Hatley <see.my.signature@for.my.contact.info> wrote:
> Oh, and I see another bug in the output of my
> celsius-to-fahrenheit converer program, that I posted about
> here a few minutes ago (re. extra blank lines form printf).

No, you don't. :)

> for (Cels = CelsMin; Cels <= CelsMax; Cels += CelsInc)
> {
> Fahr = (((Cels*180.0)/100.0)+32);
> printf("%10.3f %10.3f\n\n", Cels, Fahr);
> }

> 41.000 105.800

> Looks like the <= comparison is failing when Cels gets up to 41.000.
> I'm guessing it's somehow gets off a very small amount. Perhaps
> it's 41.00000001 when it gets compared to 41, so <= return false.

Right.

> I could change "Cels <= CelsMax" to "Cels <= (CelsMax+0.0001)".
> But that's a bit ugly. Any simpler way to do this?

It's surprisingly hard. Basically, floating point numbers generally
can't represent values that aren't exact multiples of a power of two.
"0.2" is not exact, so addition of "0.2" repeatedly is also not exact.

If you really need to do this, do all the loop controls in integer math,
then convert at the last minute using a fixed scale factor. e.g.,
loop up to 205, then divide by 5 inside the loop.

== 2 of 4 ==
Date: Wed, Mar 24 2010 3:26 pm
From: "Robbie Hatley"

"Eric Sosman" wrote:

> ...
> Robbie wrote:
> > ...
> > printf("%10.3f %10.3f\n\n", Cels, Fahr);
> > ...
>
> Note the two count them 2 count them again II zwei due
> deux newline characters ... You asked for blank lines, you
> got blank lines -- well, duh.

Yep, that time I quoted correct source. (See my post,
"Oops, wrong source file!".) That problem solved.

> > ... and the output for "celsfahr 40 41 0.001" is ...
> >
> > Cels Fahr
> > 40.000 104.000
> > 40.200 104.360
> > 40.400 104.720
> > 40.600 105.080
> > 40.800 105.440
> >
> > Where is 41.000 ??? This table should have 6 entries ...
>
> In light of the 0.001 increment, I'd have expected about
> a thousand lines. So I guess `+=' is also broken, huh?

That was a typo in my post. I should have typed,
"celsfahr 40 41 0.2". Dunno why I wrote 0.001. That's the
minimum increment the program allows, so I probably had
that on my mind.

The <= issue is also now fixed. I used a +0.0001 "fuzz zone".
(See other post.)

--
Cheers,
Robbie Hatley
lonewolf at well dot com
www dot well dot com slant tilde lonewolf slant

== 3 of 4 ==
Date: Wed, Mar 24 2010 5:04 pm
From: Phil Carmody

"Robbie Hatley" <see.my.signature@for.my.contact.info> writes:
> Oh, and I see another bug in the output of my
> celsius-to-fahrenheit converer program, that I posted about
> here a few minutes ago (re. extra blank lines form printf).
...
> for (Cels = CelsMin; Cels <= CelsMax; Cels += CelsInc)
> {
> Fahr = (((Cels*180.0)/100.0)+32);
> printf("%10.3f %10.3f\n\n", Cels, Fahr);
> }
...
> 40.800 105.440
>
> Where is 41.000 ???
...
> I'm guessing it's somehow gets off a very small amount. Perhaps
> it's 41.00000001 when it gets compared to 41, so <= return false.

Don't guess; read:
/What Every Computer Scientist Should Know About Floating-Point Arithmetic/
by David Goldberg

Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1

== 4 of 4 ==
Date: Wed, Mar 24 2010 5:41 pm
From: Eric Sosman

On 3/24/2010 6:26 PM, Robbie Hatley wrote:
> "Eric Sosman" wrote:
>> Robbie wrote:
>>>
>>> Where is 41.000 ??? This table should have 6 entries ...
>>
>> In light of the 0.001 increment, I'd have expected about
>> a thousand lines. So I guess `+=' is also broken, huh?
>
> That was a typo in my post. I should have typed,
> "celsfahr 40 41 0.2". Dunno why I wrote 0.001. That's the
> minimum increment the program allows, so I probably had
> that on my mind.

Based on a large study (sample size N=2), there's some
indication that you find it difficult to make an accurate
problem report. You might want to think about ways of improving
your accuracy, as there are situations where an inaccurate
report can be life-threatening. "Doctor, I have this terrible
pain in the diodes on my left side." "Nothing to worry about,
Robbie, just take two aspirin and call me in the morning. If
you'd said the *right* side, I'd have been seriously worried --
but on the left, I'm quite sure it's nothing to fret about.
Have a nice life!"

> The<= issue is also now fixed. I used a +0.0001 "fuzz zone".
> (See other post.)

Yeah. As others have explained, this is not a good solution.
(Given your remarks about having seen bad things "in production
code," I'm a little disturbed that you didn't know this already.
No offense meant: We all start out ignorant. But preserving one's
ignorance is not a virtue, and if you're dealing with "production
code" I urge you to cast your ignorance aside ASAP. Please.)

--
Eric Sosman
esosman@ieee-dot-org.invalid

==============================================================================
TOPIC: Hoping not to do the ugly
http://groups.google.com/group/comp.lang.c/t/8055111701d1781b?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Mar 24 2010 3:12 pm
From: Seebs

On 2010-03-24, Richard Harter <cri@tiac.net> wrote:
> On 24 Mar 2010 17:50:50 GMT, Seebs <usenet-nospam@seebs.net>
> wrote:
>>I don't think that follows. The problem is that you're requiring
>>the caller to actually pass the object, without knowing what the object
>>is. Opaque pointers and handles work by giving the user something other
>>than the underlying data to hand around. As long as you're requiring
>>them to pass the actual struct object, it's going to be pretty hard to
>>hide its contents, and no way of doing so will be elegant.

> Not so. As far as the user is concerned, they have a handle.
> Thhe fact that it is a one to one map of the bytes of the object
> is irrelevant. They can't access the contents because they don't
> know the structure of the object.

Except that, unless you figure out a way to hand them some other object
which can be memcpy'd to/from the object you want, they have to have the
structure of the object available in order to pass it as an argument.

== 2 of 4 ==
Date: Wed, Mar 24 2010 4:08 pm
From: cri@tiac.net (Richard Harter)

On 24 Mar 2010 22:12:15 GMT, Seebs <usenet-nospam@seebs.net>
wrote:

>On 2010-03-24, Richard Harter <cri@tiac.net> wrote:
>> On 24 Mar 2010 17:50:50 GMT, Seebs <usenet-nospam@seebs.net>
>> wrote:
>>>I don't think that follows. The problem is that you're requiring
>>>the caller to actually pass the object, without knowing what the object
>>>is. Opaque pointers and handles work by giving the user something other
>>>than the underlying data to hand around. As long as you're requiring
>>>them to pass the actual struct object, it's going to be pretty hard to
>>>hide its contents, and no way of doing so will be elegant.
>
>> Not so. As far as the user is concerned, they have a handle.
>> Thhe fact that it is a one to one map of the bytes of the object
>> is irrelevant. They can't access the contents because they don't
>> know the structure of the object.
>
>Except that, unless you figure out a way to hand them some other object
>which can be memcpy'd to/from the object you want, they have to have the
>structure of the object available in order to pass it as an argument.

To repeat myself, not so. There are two struct declarations,
sigil_s and pseudo_sigil. They have the same size. User code
and API code expects the pseudo_sigil format (see below). When
the system code calls user code a sigil_s struct is converted
into a pseudo_sigil struct via a cast. When the user code calls
an API it passes the pseudo_sigil struct (or copy thereof) it
received to the API. The API converts the pseudo_sigil struct it
received to a sigil_s struct, again using a cast.

The user code only sees the pseudo_sigil structure; it never sees
the sigil_s structure. It's quite straight forward.

Incidentally, as Eric pointed out upthread, the pseudo_sigil
structure needs a union to force alignment, e.g.,

struct pseudo_sigil {
union u {
long dummy; /* use the appropriate type */
char c[24]; /* get the right size somehow */
}
}

The technique is simple enough, albeit not particularly pretty.
The real objection is that there is no clean way (that I can
think of) to get the size.

Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
It's not much to ask of the universe that it be fair;
it's not much to ask but it just doesn't happen.

== 3 of 4 ==
Date: Wed, Mar 24 2010 4:09 pm
From: cri@tiac.net (Richard Harter)

On Wed, 24 Mar 2010 13:57:37 -0400, Eric Sosman
<esosman@ieee-dot-org.invalid> wrote:

Good stuff. Thanks for the comments.

Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
It's not much to ask of the universe that it be fair;
it's not much to ask but it just doesn't happen.

== 4 of 4 ==
Date: Wed, Mar 24 2010 5:16 pm
From: cri@tiac.net (Richard Harter)

On Wed, 24 Mar 2010 08:24:08 -0700 (PDT), ImpalerCore
<jadill33@gmail.com> wrote:

>On Mar 24, 10:59=A0am, c...@tiac.net (Richard Harter) wrote:
>> On Wed, 24 Mar 2010 02:07:32 -0700 (PDT), Nick Keighley
>>
>> <nick_keighley_nos...@hotmail.com> wrote:
>> >On 23 Mar, 21:53, c...@tiac.net (Richard Harter) wrote:
>>
>> [snip]
>>
>>
>>
>> >How have you got into the state where you trust your users so little?
>> >Would you be better off with a less low level language where you have
>> >more control over what they do?
>>
>> It is not a question of not trusting users; the objective is to
>> create trustworthy code. =A0If the user can easily or inadverently
>> break my code then it is not very trustworthy. =A0The closer code
>> is to the bottom of the pyramid the more trustworthy it should
>> be.
>
>If these are errors of ignorance, maybe more education is needed? If
>these errors aren't being made maliciously, maybe a FAQ or a set of
>verbosely documented examples for your users to follow would be more
>useful.

These are always good things, of course, but not quite to the
point. If a user error breaks my code, I share the blame. If my
code is robust user errors won't break it. The purpose of
education is to help the user use the software more effectively;
it shouldn't be about navigating around booby traps left in the
code.

Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
It's not much to ask of the universe that it be fair;
it's not much to ask but it just doesn't happen.

==============================================================================
TOPIC: Reading lines from a text file
http://groups.google.com/group/comp.lang.c/t/5d6be78418b75b97?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 24 2010 2:55 pm
From: "bartc"

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnvdclzdz9.fsf@nuthaus.mib.org...
> "bartc" <bartc@freeuk.com> writes:
> [big snip]
>> What seems wrong is to let the input file dicate to you some ridiculous
>> 'line length' of perhaps a billion characters, and to go along with that.
>
> What seems wrong to me is to let limitations in the program impose
> some arbitrary limit on line length, when the input format you're
> trying to process imposes no such limit.

OK, but then be prepared for your getline() function to actually need to be
a getfile() function with some input, and to potentially grab most of the
memory in your system, or even to bring down the program (if a giant file
uses the wrong newline format for example).

--
Bartc

==============================================================================
TOPIC: Has thought been given given to a cleaned up C? Possibly called C+.
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Mar 24 2010 3:50 pm
From: Tim Rentsch

James Kuyper <jameskuyper@verizon.net> writes:

> Richard Delorme wrote:
[snip]
>> - void can be removed from the language. So instead of declaring
>> void f(void);
>> we can simply write :
>> f();
>> The generic pointer type (void *), could then be replaced by (char*)
>> without much harm.
>
> Using 'void' to indicate "no return type" or "no arguments" was bad
> design, necessitated by issues of backwards compatibility. I have no
> objection to a new language where you can express those things by the
> absence of a specified return type or the absence of specified
> arguments. [snip futher unrelated comments]

Using 'void' for no arguments -- sure, clearly that choice was
dictated more by backward compatibility concerns than by good
design guidelines.

Using 'void' to mean no return value -- good design, not bad.
Makes the language more uniform syntactically, more uniform
semantically, with fewer special cases, with result that is
smaller, simpler and cleaner. Leaving 'void' out in these
cases would be like those proofs from the ancient Greeks,
where the arguments had to be made twice, once if the
value in question was 1, again if the value in question
was not 1, because (according to their thinking) 1 wasn't
a number...

== 2 of 3 ==
Date: Wed, Mar 24 2010 4:04 pm
From: Ben Pfaff

Tim Rentsch <txr@x-alumni2.alumni.caltech.edu> writes:

> Using 'void' for no arguments -- sure, clearly that choice was
> dictated more by backward compatibility concerns than by good
> design guidelines.
>
> Using 'void' to mean no return value -- good design, not bad.
> Makes the language more uniform syntactically, more uniform
> semantically, with fewer special cases, with result that is
> smaller, simpler and cleaner.

But it also preserved backward compatibility, since pre-C89
versions of C assumed an "int" return type if none was
specified.
--
Ben Pfaff
http://benpfaff.org

== 3 of 3 ==
Date: Wed, Mar 24 2010 4:13 pm
From: Tim Rentsch

Keith Thompson <kst-u@mib.org> writes:

> "Rod Pemberton" <do_not_have@havenone.cmm> writes:
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>> news:lnk4teiqf2.fsf@nuthaus.mib.org...
>>> "Rod Pemberton" <do_not_have@havenone.cmm> writes:
>>> > "Keith Thompson" <kst-u@mib.org> wrote in message
>>> > news:ln6350jazh.fsf@nuthaus.mib.org...
>>> >> "Rod Pemberton" <do_not_have@havenone.cmm> writes:
>>> >> > "bartc" <bartc@freeuk.com> wrote in message
>>> >> > news:pPNln.49083$Ym4.30216@text.news.virginmedia.com...
>>> >> [...]
>>> >> If I were
>>> >> redesigning the switch statement from scratch, you'd be able to
>>> >> specify multiple values in a single case, the "break" keyword
>>> >> would not be required, and there would probably be special syntax
>>> >> to specify falling through to the next case.
>>> >>
>>> >
>>> > That works. It's not my first choice though. It just transposes the
>>> > locations where one must add additional control flow. E.g., "break;" is
>>> > removed, while, say, "fallthru;" is added. It's much like rewriting a
>>> > loop with "break's" to use "continue's" instead.
>>>
>>> Except that "fallthrough;" (yes, I'd insist on spelling it correctly)
>>> would be much rarer than "break;" is in current C code. Make the
>>> normal case the default, and require a little extra work for the
>>> exception. Of course it's too late to change this in C, unless we
>>> leave the switch statement alone and add a new form of selection
>>> statement (something I'm not advocating).
>>> [...]
>>> It also imposes an arbitrary ordering on the cases and restricts
>>> which cases can fall through to which other cases.
>>
>> What about "recase" or "reswitch"? E.g., perhaps like so:
>>
>> case 0x10: recase (0x30);
>> case 0x20: /* stuff */
>> break;
>> case 0x30: /* stuff */
>> break;
>>
>> The advantage is you don't need a goto label. The ordering can be as one
>> wishes. And, each case could then be auto-break. Hmm, that's not too bad,
>> IMO.
>
> So "recase" is just like "goto", except that it jumps to a specified
> case label rather than to a goto label.
>
> Ok, that might not be an entirely bad idea. Let's explore it a bit.
>
> I don't think the parentheses are necesssary: "recase 0x30;" should
> suffice, though of course the expression can be parenthesized if you
> like.

If we're really going to consider adding a 'recase' construct,
why not call a spade a spade, or more accurately call a goto
a goto:

case 0x10: goto 0x30;
case 0x20: /* stuff */ break;
case 0x30: /* stuff */ break;

The syntax for 'goto' would need to be expanded to take an
expression rather than just a label. If the target of a goto is
a label defined in the function (which would take precedence) or
an integer constant expression matching one of the 'case's in the
nearest-most enclosing switch block, the target is allowed, with
well-defined and easy to understand semantics.

> Presumably "recase default;" would be permitted. Would a "recase"
> statement that targets a nonexistent case label be a constraint
> violation, or would it jump to the "default:" label if it exists,
> or terminate the switch statement if it doesn't?

And 'goto default;' is easy to recognize, because 'default' is
reserved for use as a keyword. Again the nearest-most enclosing
switch would need an entry for this 'switch' choice.

> What does it do in the presence of nested switch statements?
> I'd guess that it would apply only to the innermost one, but
> it would have to be specified.

Alternatively, for those folks who like less restrictions on
their control flow, 'goto <expression>;' or 'goto default;'
could accept any enclosing 'switch'-block choice as a destination.
Personally I like the more restrictive form, but hey, why make
folks have to work harder just because they want to get to
an outer 'switch'-block choice that already has a perfectly
usable label just sitting there, waiting to be transferred
to?

> It still creates just as much opportunity for abuse as the goto
> statement itself. If you want to write BASIC in C:
>
> int line = 10;
> switch (line) {
> case 10:
> puts("Infinite loop");
> recase 20;
> case 20:
> recase 10;
> }
>
> The "recase" statement could be defined consistently, but I don't
> believe the benefits would outweigh the cost.

Not even if we added a differentiating keyword, eg,
'goto static 20;'?

[snip additional material that offered no special opportunities
for silly humorous response comments like the ones made above]

==============================================================================
TOPIC: Why doesn't fscanf fail when it doesn't find ordinary characters (
specified in format) in the input?
http://groups.google.com/group/comp.lang.c/t/d2c05bf5fc6faf58?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 24 2010 4:06 pm
From: David Thompson

On Wed, 10 Mar 2010 14:47:06 +0000, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

> Disc Magnet <discmagnet@gmail.com> writes:
<snipped>
> If you want to force fscanf to fail visibly (i.e. return a count of
> matching items less than you'd expect) you can ask it to read and
> return a comma:
>
> char dummy;
> if (fscanf(fp, "%d%1[,]", &csv[i][j], &dummy) != 2) break;
>
Nit: %N[chars] can store N chars (here 1) PLUS a NUL, so officially
you need char dummy[2]; and &dummy[0] or just dummy.

==============================================================================
TOPIC: Casting jmp_buf to void *
http://groups.google.com/group/comp.lang.c/t/a9e559468513ce12?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 24 2010 4:31 pm
From: Tim Rentsch

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

> On 3/23/2010 10:16 AM, Tim Rentsch wrote:
>>
>> [...] Notice that using the '&' as you have here,
>> and casting to a pointer type upon converting back, means this
>> technique will work whether or not jmp_buf is an array type.
>
> 7.13p2: "The type declared is jmp_buf which is an array
> type [...]"

Yes I know that. My point is that it's better as a general rule
not to write code that depends on that if we don't have to, and
we don't have to. And it's easier on the reader -- not everyone
knows the C Standard to the level of detail that clc'ers
generally do. And, what I think is most significant, the later
use of said pointer value being converted to type 'jmp_buf *',
using '&env' rather than just plain 'env' will cause less head
scratching in general -- even people who _know_ that jmp_buf is
an array type might take a moment or two to remember that. There
are plenty of things to think about when reading code more
important than this; when I write code I don't want readers of
that code to spend even one second thinking about stuff they
don't have to.

==============================================================================
TOPIC: Does GCC optimize variadic functions to death?
http://groups.google.com/group/comp.lang.c/t/00b2bccdde28fde4?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 24 2010 5:03 pm
From: Tim Rentsch

pacman@kosh.dhis.org (Alan Curry) writes:

> In article <cfc0d53b-a8d0-4986-955f-15793c9cfd23@g19g2000yqe.googlegroups.com>,
> Elmar <elmar.krieger@gmail.com> wrote:
> |
> |The problem is that in real life, lst_print from my minimum example is
> |a much larger function, which I don't want to write twice, once as
> |shown originally (other functions need to call it with a list, not
> |with variable arguments), and once as typed out by you (would be a
> |nasty code duplication).
> |
> |So the only correct alternative would be to turn val_print into a
> |wrapper for lst_print, and use va_start and va_arg to create a list
> |that is then passed to lst_print. This would require malloc/free etc.
>
> It doesn't require all that... it just requires a couple of C99 features:
> a variadic macro and an array literal.
>
> #define val_print(...) lst_print((int[]){__VA_ARGS__})
>
> There you have something that can be used like a variadic function, but
> compiles as a call to a function that takes a pointer to the first element
> of an array. And only one copy of the list is generated. [snip incidental]

Good idea, to which I would like to suggest an addition, namely,
an additional argument giving the number of elements in the array,
(computed using the usual 'sizeof x / sizeof *x' technique).
Details left as an exercise for the reader.

> There will probably be an array-copy operation in the generated code, but
> your original version had a bunch of stack pushes, which did an equivalent
> amount of copying.

The array-copy operation might be avoided if the function
parameter and compound literal used 'const int' rather than 'int'
(and the array values were constants not needing run-time
computation).

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

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

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

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

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

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

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

twitter

Wednesday, March 24, 2010

comp.lang.c - 25 new messages in 8 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts